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the end of the reporting period (June 1971) . Chapter 2 describes 
development progress in two different areas: the bibliographic 
services and system design as seen by the user; and the software and 
hardware design to support these services (including video terminal 
selection and screen design) . Chapter 3 describes the major standards 
and analytic studies completed during the design. Each of these 
standards or studies became a part of the design, or had a 
substantial effect on the user, hardware, or software design 
described in chapter 2. Chapter 4 describes the activities currently 
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CHAPTER 1 
INTRODUCTION 



1,1 SCOPE OF REPORT 

BALLOTS I was concerned with the conceptual design, implemen- 
tatlon, and evaluation of a prototype. system of computer support 
for bibliographic operations In large libraries and with provl io 
fir extensions to other libraries. BALLOTS II Is concerned with 
the development and Implementation of the firojUCtlQA . 

library automation system--the system that will support the d y 
to-day operations of the library. 

The development and implementation of BALLOTS II are divided 
Into si x parts. The first of these. General f'* a ? p Inal 

described along with the prototype system in the BA ^OTS Final 
Report, (The BALLOTS I Final Report covered the per od fiom dune 
1967 through June 1970.) The next three parts. Detailed 
Ana 1 vs 1 s General Design, and Detailed Design, are the subject of 
thls^eport, which covers the period from July 1970 through June 
1971 Office of Education support for BALLOTS II (grant 
OEG-0-70-2262) continued through March 31, 1971. In the Interest 
of providing continuity, this document describes work In progress 
during the grant period but completed during the following ninety 

days. 

The final two portions of BALLOTS II development. Implemen- 
tation (programming, training users, testing) and Instal 1 
(file conversion, pilot operation, and acceptance testing), are 
in progress as this report goes to press. At the end of January 
1972, programming has progressed to the point where a 
1,200-reeord MARC tape has been converted to an on-line r, ‘ a ' 
full indexes have^been built for this file, and on-line searching 
and display of the search results have been done on both a 
typewriter terminal and a CRT (cathode ray tube) terminal. The 
remainder of the acquisition and cataloging CRT screen £°™ats 
and printed output formats are being coded. Schedule*, are being 
drawn up for MARC tapes file conversion and for training computer 
machine room attendants. The printing forms have been ordered 
for various outputs, and catalog card eutters are being 
evaluated. Computer cost accounts are being arranged so that 
detailed cost figures can be collected for such categories as 
supplies, terminal rental, on-line activity by library 
department, printing, file maintenance, etc, Training and 
reference manuals for users are being drafted. Communication 
lines are being Installed for use with the CRT terminals to 
be delivered In February and March 1972. 
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The present report is divided into four parts. Chapter 1 
gives some background for the report and summarizes the nature of 
the BALLOTS system, as well as its status at the end of the 
reporting period (June 1971). Chapter 2 describes development 
progress in two different areas: the bibliographic services and 
system design as seen by the user; and the software and hardware 
design to support these services (including video terminal 
selection and screen design). Chapter 5 describes the major 
standards and analytic studies completed during the design. Each 
of these standards or studies became a part of the design, or had 
a substantial effect on the user, hardware, or software design 
described in Chapter 2. Chapter 4 describes the activities 
currently under way (following the reporting period) and future 
pl ans. 



1.2 BACKGROUND 

In 1967, Stanford began a continuing library automation 
project, BALLOTS--BI bl iographic Automation of Large Library 
Operations using a Time-sharing System. A final report on the 
first phase of BALLOTS (July 1967 through June 1970) was 
submitted to the Office of Education in April 1971 <1>. That 
report reflects the work done under grant 0EG-1-7-071145-4428 . 

The present report reflects work done under a continuation grant, 
OEG-0-70-2262. Readers are referred to the earlier report for 
details of development related and leading to the contents of the 
present report. However, for the benefit of readers who do not 
have ready access to the earlier report, a brief summary ts given 
In the following sections, 1.3 through 1,6. 

Project BALLOTS Is directed toward maximizing the 
contribution of the large library to university education. 
(Through Its generalized design and network capabilities, BALLOTS 
facilities are extendable to libraries of various types and 
sizes — see section 3.7). Increasing costs of operation and the 
limitations of a manual file system inhibit the library s 
response to the changing information requirements of higher 
education. The BALLOTS approach Is to provide technological 
assistance to the library and the academic community In the form 
of an on-line production blbl Iograph|c processing system. The 
project has been conducted in two major phases: (1) BALLOTS i, 
research and prototype development, completed at the end of 
calendar 1969, and (2) BALLOTS II, production system development, 
the present activity. 

BALLOTS has been conducted as the collaborative effort of 
the Stanford University Libraries, the Institute for 
Communication Research, and the Stanford Computation Center* The 
project Is monitored by an executive committee chaired by Provost 
William F. Miller. The BALLOTS project director, Mr. A, H. 



Epstein, holds a joint appointment with the Library and the 
Computation Center. Shared software (see section 1.5) Is being 
developed with the Stanford Institute for Communication Research, 
which Is conducting Project SPI RE5--Stanford Public Information 
REtrleval System, SPIRES Is funded by the National Science 
Foundation, With a project structure that links the campus 
computer center, related Information retrieval activity, and the 
working library staff. It has been possible to coordinate 
operating needs, technical factors, and design capabilities. 



1.3 THE PROBLEM 

The large research library Is caught between the spiraling 
costs of maintaining a crucial but cumbersome system of manual 
files and the demanding social and educational forces that are 
reshaping the university environment. Labor costs have mounted 
sharply while large libraries have had to enlarge their staffs 
merely to cope with the Increased size and complexity of their 
files. Despite current cutbacks and leveling off In the rate of 
library growth, there Is good reason to believe that the overall 
trends will be upward to the end of this century. In this same 
period of rising costs. Information and educational technology 
have made great strides. This Is Indicated by the availability 
of machine-readable data bases (such as MARC tapes and census 
tapes), computer-assisted Instruction, the wide use of 
audiovisual equipment, the continuing experimentation with cable 
TV, and the development of regional computing networks. 

Changes In the tools and materials of education are 
paralleled by changes In orientation and methods, Stanford, like 
other universities. Is emphasizing the extension of quality 
education to minority and disadvantaged groups. There Is a 
growing Interest In the social and ecological effects of 
technology, arid In the Improvement of our society In the face of 
social turmoil. Colleges and universities are being called on to 
divert resources from traditional channels and disciplines to 
new, problem-oriented programs that are often Interdisciplinary, 
Students are encouraged to make broad and Independent use of the 
Intellectual resources of the university. Faculty members 
require up-to-date Information to support research Into the 
social and' economic problems of the nation. It Is generally 
acknowledged that today's most critical problem in the academic 
world Is the limited resources available for fulfilling these new 
responsibilities. Networks and shared facilities, systems based 
on new technology, plus efforts to promote standardization, 
appear to be the only practical remedies In the current 
environment. 

The role of the library Is to support these constructive 
changes In American higher education with efficient use of Its 
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operating dollars and with Improved services. The 
requirements of the university are changing rapidly; the services 
of the library must change to meet these requirements, 
creation of an on-line library automation prototype (BALLOTS I) 
was a major milestone In this effort, 

1,4 OBJECTIVES 



The 



overall objective of Project BALLOTS Is to Improve the 



1 Ibrary's contribution to university education through the 
application of computer technology ‘«; lb ”^ r0 “ 5 ; ir ' 

large library Is a production process ng system that quires 

library materials and makes them available to users, 
materials and Inquiries about them a 

:« kni-h thf* fArhnlcal processing and circulation areas. vwsts 
and qSalUy of service a?e a function of the speed and accuracy 
with which the procedures and flies of the library suppor 
highly trained staff. BALLOTS II focuses on Improving this 
support with an on-line production processing system. It I 
expected that the results will inc ude l mpr°vecl qua! I ty of 
service; more powerful search facilities; system flexibility, far 
fewer flies to maintain; automatic production of management 
rtTortl and statistics; economic utilization of Library of 
Congress cataloging; better control over materials being 
processed; shared files and original cataloging among the 
Institutions using the same system; and some reduct _ . 

Inadvertent duplication of purchases among network Institutions. 

The kev to a library's store of knowledge Is Its file of 
bibliographic records. The multitude of paper and card files 

to order and prepare books for use, control their 
circulation, and provide blbl lographic informat on (through the 
card catalogs) to users are expensive to maintain and 
increasingly cumbersome to use. The machine-readable files 
created by BALLOTS II will be more responsive to the users and 

the library staff In three ways, (1) They will be more 
SS-ti-date because of the speed with which changes to ’"dividual 
records and to an entire group of records can be made. ^ Each 
record will have a greater number of access points than exists 
for tb« present individual record stored In a manual file. ^ , 
Several users will be able to use the same record slmu taneously, 
and BALLOTS II files will be accessible to remote terminals s. I t 
wHl be increasingly unnecessary for the user to come t> o a file, 
since the file will be available wherever a terminal Is located. 

Accurate knowledge of the status of 1 Ibrary i mater J{|1 
It Is available on the shelves Is necessary for both 1 1 b ^? r I* 
a^d library patrons. Accurate knowledge of what I boo *| 
order assists In avoiding unnecessary duplication. Accu J[?^® h 
knowledge of where a book Is in technical processing enables the 
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library to advise a patron when a book will be available and to 
provide rush service when needed. With a manual system such 
information Is difficult and time-consuming to obtain, BALLOTS 
II *Iles will provide the librarian and the patron with immediate 
status information. 

The growth of I nterd t sci pi inary research and teaching Is 
placing a heavy demand on library resources and frequently 
results In undes l reabl e, unnecessary duplication of library 
materlals--a situation that is difficult to tolerate when book 
and periodical prices are rising at annual increments ranging 
from 10 to 20 percent. Centralized machine control of materials 
purchased for many academic departments and branch libraries is 
expected to aid In controlling these costs. Of particular 
assistance will be the ability to search files rapidly from 
remote locations and to communicate the results more rapidly to 
the patrons there. The value of such automated record keeping 
and rapid communication Is Incalculable to a network of 
cooperating libraries, because It offers the possibility of more 
rational sharing of resources“-partlcularly book budgets. 

The proposal of March 1970, which requested funds to begin 
BALLOTS II development, stated the following objective. Although 
the necessary funding to complete Project BALLOTS as originally 
scheduled was not continued after the end of this reporting 
period, and thus only "part 1" of Phase II was completed, brief 
conclusions have been Inserted below after each component of the 
main objective, 

"The main objective of Phase ti of Project BALLOTS Is to 
apply the learning from the eompl eted bas lc research and 
prototype operations in Phase I to the creation of a fully 
operational, computerized system for the bibliographic management 
of the large library system. The components of this basic 
objective in Phase II are as follows: 

"Reliability, file security, and rapid recovery from 
downtime must characterize the operational system." 

<This component is being developed and will be tested 
In operations. In order to improve the reliability 
of the file and to allow for file recovery, the 
following design has been adopted. Whenever a new 
record Is added to the file or an existing record Is 
modified In the file, a copy of the new or modified 
record is placed in a separate data set called 
a "deferred update queue," Once a record has been 
placed in the deferred update queue, any user attempt- 
ing to reach the old record in the main file will 
automatically be routed to the modified record in 
the deferred update queue. Thus the user sees the 
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latest version of the record and Is unaware that the 
main file has not yet been physically updated. To 
meet file security and file recovery requi rements, 
two copies of the deferred update queue are kept on- 
line on different physical disk drives. At night 
when the on-line system Is no longer operating, the 
deferred update queue will be dumped to a tape and 
the on-line main file will be updated with the new 
and modified records. The on-line file indexes will 
also be modified at this tlme.> 

"The operating costs of a production-engineered 
system must be less than or reasonably competlt ve 
with the costs If a manual system had been retained. 

Preliminary cost calculations show that the on-line 
system will be more expensive than the present 
manual system for a period of approximately five to 
ten years. After this period of time, the automated 
system Is expected to be less expensive than the manual 
system. One of the reasons for the time lag Is the 
fact that displaceable costs do not become cash savings 
until the library has been able to reduce staff through 
"attrition." If the benefits derived from the displace- 
able costs are considered as savings, then the break- 
even point would be reached much sooner. Another 
unknown factor at this time is the Income from the 
network of libraries that will use BALLOTS. Since 
the system Is not operational as this report Is being 
written, actual measurements and costs are not available; 
high-cost calculations were therefore used to determine the 
operating costs of the system. It will be possible to cal- 
culate costs much more accurately after several months of 
production operation, > 

"Multiple data bases and multiple users must be served. 

As expressed in earlier proposals and reports, central- 
ized, computer— ma 1 nta I ned files should be remotely 
accessible. " 

<Th l s component is assured. Both the BALLOTS I 
and BALLOTS M designs have permitted access 
to a number of data bases and access to the same data 
base concurrently by a number of users. The BALLOTS 
I! MARC file can be used by several typewriter and 
video terminals simultaneously with no noticeable 
degradation in service. > 

"The system must be general I zabl e for external transfer 
to other Institutions or regional utilities, such as 



library regional processing centers operated either 
by the private or by the public sector." 

<Thls concept Is to be tested by the California Library 
Automation Network--see section 5,7, One of the requirements 
that must be met by each library In the network Is 
that the library must review# revise as necessary# 
and accept the specifications for each module. As 
this report goes to press# several of the network 
libraries have reviewed the BALLOTS-MARC requirements 
documentation; these have requested relatively Insig- 
nificant changes to accommodate their use of BALLOTS- 
MARC, This experience has been most encouraging# 
and If the remaining modules follow the pattern of 
BALLOTS-MARC# this objective will have been met . > 

"User requirements rather than machine convenience 
should continue to dominate the design," 

<Thi s has been true and will be tested In operations, A 
major design task has been designing the user/vl deo-terml nal 
Interface, The requirements for CRT terminals were 
determined as a function of the user Interface; and 
only after these requirements had been drawn up was 
a CRT terminal sought that would satisfy them. Sections 
2,4# 3,2# and 3.3 of this report describe this work. 

A programmable terminal was chosen because none of the 
available hardwired CRT terminals would satisfy all 
of the criteria established by the BALLOTS project. 

The features that have not been found In existing 
CRT hardware will be added as software to make the 
system as convenient and flexible as possible for 
Its users. > 

"Service levels for processing transactions must 
be lmproved--not Just maintained at the present 
level — In the face of Increasing work loads." 

<Thts component Is assured. Once the system Is In 
operation# It will be possible for the processing load 
to grow substantially without requiring additional 
manpower. We expect that the terminal operators will 
be able to handle a significantly heavier work load 
under BALLOTS than they are able to under the present 
manual system. In addition to this# the BALLOTS 
system can be expanded to add new modules that make 
possible new types of services# unavailable under 
the present manual system. It Is expected that much 
of this expansion of services can also be done without 
additional manpowers 
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1.5 SHARED SOFTWARE 



Shared software Is an important concept In BALLOTS and 
SPIRES development. BALLOTS Is a data management system for 
libraries; SPIRES Is an Information retrieval system geared to 
the needs of researchers In many disciplines and Involving many 
data bases Both applications require substantially the same 
baste sof twaref or file services (file building, update, treat on 
of Indexes), retrieval (parsing, decoding of command languages), 
and output (printed reports and CRT display of search results). 

In the BALI OTS prototype system, the foli owing was achieved 
through common software and described In the BALLOTS I Final 
Report 



1. On-line, Interactive searching permitted 
users to conduct file searches l n which 
they could easily modify, expand, and contract 
search requests, and save the early. Intermediate, 
and final results. An operator could complete 
a typical complex search within one or two 
minutes, a simple search In a few seconds. 



2, Several data bases were serviced by this 
software. This feature was Implemented 
on five different data bases: the University 
Libraries' In Process File, ERIC, preprints In 
high-energy physics, and two Individually 
maintained files, one on African history and 
one on geology. 



3 Several users could search simultaneously 
the same or different files without 
Interference to one another. 



4. The sample outputs from library technical 
processing were demonstrated for search 
results, purchase orders, and other printed 
forms, 

5, Computer or programming knowledge was not 

a prerequisite for users; productive results could 
be obtained after a few hours of training 
and experience. 

6. The user was able to communicate his satisfaction 
or dissatisfaction with the on-line system easily 
and directly during a terminal session. Thus 

the user became part designer and his feedback 
Influential In arriving at the production system. 

To the above list BALLOTS II adds file Integrity and file recovery 
software (see the description of this In section 1. )• 
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1.6 DEVELOPMENT STATUS 



The prototype system/ BALLOTS I # was Implemented/ operated/ 
and evaluated In 1969, This provided the foundation and 
experience to design and Implement a production system/ BALLOTS 
M/ an effort that Is still In progress. Details of the 
organization/ staff/ facilities/ and results of the prototype 
system development are given in chapter 2 of the BALLOTS I Final 
Report . 




In the period covered by this report/ July 1970 through June 
1971/ user requirements were defined for major system processes/ 
such as ordering/ receiving/ and cataloging (sections 2.1 and 
2.2), Video terminals were evaluated and the Sanders PDS (804) 
terminal was selected (sections 2,4.8 and 3.2). Video terminal 
screen formats were designed (sections 2,4 — passim — and 3,3), 

Host computers for BALLOTS I! development and Implementation were 
studied and one was chosen (section 3.1), The BALLOTS on-line 
command language was developed (section 3,4)/ a notation system 
for describing data elements In various formats devised (section 
3,5)/ and the programming language selected (section 3.6). 
Programming basic software to support file services/ on-line 
Interactive searching/ printed outputs/ and recovery procedures 
cont 1 nues. 

When Office of Education support was terminated In the first 
half of 1971/ It became necessary to alter the system development 
approach. With the single omission of serials/ the original 
approach to BALLOTS It was Identical to that for BALLOTS I: 
large-scale/ system-wide applications to sequentially related 
functional areas — acquis 1 1 Ion, cataloging# and cl rculat ion. * 

With the goal of achieving near-term operations within the more 
limited resources aval lable# It was decided to adopt a modular 
approach. This had several advantages s automation could be 
Introduced more gradually; almost all parts of the 
1 lbrary--lneludlng potential network members--couId begin 
participating In BALLOTS at once; and modules providing the most 
benefit to the greatest number of users could be Introduced 
first. The modular approach is further detailed in section 2.3. 



•Although serials were to be covered In the BALLOTS I 
design# this was decided against for BALLOTS II owing to library 
staff priorities and the nature of the Justification for 
automating on-line. The following paragraphs explain the 
distinction made between serials control and the other areas of 
technical processing that led to excluding serials from BALLOTS 
I I * 

Much of the effort in recording serials lies In the manual 
handling of the several hundred thousand Individual pieces 
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The BALLOTS-MARC module will be the first to be Implemented 
(see section 2,3). BALLOTS-MARC will enable users to search the 
MARC file Interactively from a variety of access points (personal 
name/ corporate name# title words, and Library of Congress card 
number) singly or In combination. Implementation is planned for 
spring 1972; CRT terminals have been ordered, delivery dates 
specified, and a PDP-11 Interface computer Installed to service 
the CRT terminals. 

Major tasks confronting the designers of bibliographic 
systems using time-sharing include: (1) Identification of system 
requirements, (2) access to a machine with adequate resources to 
Insure satisfactory service, (3) reasonable pricing to provide an 
affordable service, (4) rapid recovery from machine and system 
downtime, (5) complete file Integrity, I.e,, no loss of records, 
(6) selection of a video terminal suitable for the Input and 
display of bibliographic records, (7) design of file services, 
on-line Interactive software, and applications programs, (8) 
documentation, (9) user training, and (10) resource management. 
The methods for attacking these problems have been documented In 
the Final Report on BALLOTS I, 



recalved each year--a task In which the computer offers no 
assistance. Additionally, the efficiency and economy of 
Stanford's manual serials control system has presented a 
consistent and strong obstacle to a move towards computerization. 
The department In the Main Library controls some 26,000 current 
titles, plus retrospective records; It functions with a small but 
dedicated nonprof ess lonal staff, and Its work Is always up to 
date; It has suffered temporary backlogs only as a result of 
factors beyond Its control, I.e,, dock strikes or mall strikes. 
Procedures In the manual system are consistent, well designed, 
and well taught. 

There are two areas In which some assistance may be derived 
from the computer, but neither requires an on-line response; one 
Is file secur I ty--the current manual file Is backed up only by a 
microfilm that records file status as of the date of filming. 

The second area Is claiming, which is a housekeeping task of sub- 
stantial nuisance value, but not unbearable, and can be served 
effectively through a batch system. The University Is currently 
considering preparation of an expanded (and ultimately complete) 
printed union list of serials with generalized holdings. 

Coverage Is presently confined to currently received science and 
technology titles. The completion of this task Is belfeve^to 
offer a more economical solution to effective public service as 
well as some assistance to security problems with serial records 
than would development of an on-line control system. 
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BALLOTS' experience has shown that the use of an on-line 
facility for managing the baste bibliographic operations of a 
large library and of a cluster of nearby libraries Is feasible 
and sound. The technical problems are substantial but solvable# 
using a central# shared facility supporting both library and 
other users. Economical use of the available computing resources 
(including manpower) Is the principal challenge to the designer. 

We recommend that the BALLOTS project be carried to 
completion and that BALLOTS form the system for a regional 
network In Northern California; such a network has been 
designated CLAN' — California Library Automation Network (see 
section 3.7), 



1,7 RELATED RESEARCH 



The expense and complexity of library system development 
have been recognized for several years and have been documented 
<2# 3> , At one time It seemed natural to suggest that development 
work might be shared and that certain elements of system design 
be commonly developed by several Institutions. Thus far such 
hopes have not been realized. Despite the attractiveness of the 
Idea of collaborative development# It continues to elude 
researchers. Under a grant from the National Science Foundation# 
three university 1 Ibrarles— Chicago# Columbia# and 
$tanford--began a project In 1968 to test the feasibility of a 
collaborative design effort. Although the project did not 
achieve its goal of creating a unified system design for a target 
process (acquisitions)# It did provide an understanding of the 
staggering proportions of large-scale system development In both 
the human and technical areas. The material In Appendix A# 
extracted from the Final Report on Collaborative Library Systems 
Development (CLSD)# summarizes the conclusions reached by 
participants in the joint effort. 
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CHAPTER 2 



BALLOTS II BIBLIOGRAPHIC SERVICES DESIGN 



2,1 BALLOTS DESIGN REQUIREMENTS 

BALLOTS Is predicated on the application ofvldeo terminals 
for the following reasons: Cl) patrons or Hbrarians should be 

able to conduct searches rapidly *» ' 1 area* <?>* 

fact lft I es S for S se If -instruct !o n a and b for TSSilS, and'correct. ng 
error's should be Incorporated Into library procedures# to 

minimize mistakes and ! ncrease throug hput. iSpraphtc^ervI ie 
mind# the general features of the BALLOTS bibliographic 

design are as follows: 

1, Access throughout the normal working day to automated 
acquisition# cataloging# and circulation services. 

2, Implementation as a series of modules ( jets of 
Interrelated services)# with each module achieving stable 
production status before another module Is Implemented. 

3, User Interaction with the system via video display P" 1 ts 
In network libraries# In the Stanford ^^rary# and throughout the 
Stanford community. (The library files will also be 

for searching via the more than 130 typewriter terminals on and 

off campus . ) 

4, In order to ensure reliable network operations# 
Implementation of all files and services fI rst at Stanford# to be 
released to netivork members only after thorough testing, 

5 Four on-line files: a six-month to one-year file 9f the „ 

most recent MARC data# an In Process File ( 1 °£, f* 1 (CDF)®” 

order or In technical processing# a Catalog Data File 
ail titles cataloged# and a Circulation Inventory File ( INV) of 
all titles In Stanford's Meyer Undergraduate Library collection, 

6. Multiple Indexes for each file# such as author# title# 
and LC card number# and an easy-to-use command language wit 
Boolean search capabilities, 

7, Printed outputs: purchase orders# technical processing 
control forms# catalog card sets# book spine labels# and 

management statistics. These will all be ava t^create 

Implementation of the first module. Users will be ab e to create 
bibliographies from selected portions of flies. It win oe 
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possible to produce lists of new acquisitions by subject and to 
send them to special user groups or academic departments. 

8. Reliability/ fast recovery/ and file protection as an 
Inherent part of the sof tware-hardware design. 



2,2 LIBRARY SYSTEMS ANALYSIS 

The bibliographic services design originally conceived In 
BALLOTS I concentrated on the functional aspects of library 
technical processings a series of complete subsystems for 
acquisition/ cataloging/ circulation/ and serials control. Each 
major subsystem was broken down Into a series of processes. The 
acquisition subsystem consisted of ordering/ receipt of purchase 
order materials/ receipt of non-purchase order materials/ Invoice 
receipt/ dealer report receipt/ automatic claiming/ cancelling/ 
forced claiming and cancelling/ and MARC conversion. The catalog 
subsystem consisted of distribution and MARC searching/ Library 
of Congress (LC) cataloging/ original cataloging/ Meyer 
cataloging/ added copies and volumes/ and maintenance. The 
circulation subsystem consisted of lost book billing/ charging/ 
circulation search/ discharging/ delinquency/ fine payment/ fine 
search/ hold/recall/ Initial check-ln/ missing/ overdue/ and 
patron search. The reserve processing subsystem consisted of 
reserve book processing/ reserve ordering, reserve search/ 
reserve book listing/ and off reserve. 

During the reporting year / the acquisition and catalog 
subsystems were fully documented. In addition to the five 
BALLOTS analysts/ three members of the library staff worked on 
this documentation at the project site for three months. The 
documentation comprises a process book for each process In each 
subsystem plus a system book common to both the subsystems. 

These assembled volumes contain over 1/000 pages. 

A process book begins with a flow chart and a narrative 
description of the process. Then follow a series of forms 
describing each of the Inputs and outputs of the process/ the 
video terminal screen formats and the files used in the process/ 
and the manual and manual -automated procedures performed In the 
process. Appendix B contains the narratives and flow charts from 
two of the acquisition and two of the cataloging process books 
produced. Statistics were gathered from library staff/ and 
estimates of the volume of printed outputs/ searches/ video 
terminal usage/ file updates/ etc,/ within each process were 
made. As the process books were completed/ they were reviewed by 
supervisory librarians tn the appropriate departments/ and 
changes requested were Incorporated Into the documentation. 

The system book contains data that is common to all of the 
processes. For Instance/ an Input screen format may be used In 
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this 

book 



system 
expl felt 



both ordering and cataloging. The format and the editing rules 
that apply to It are defined In the system book; the descriptive, 
procedural, and statistical Information about a process using 
Input format are documented In a process book. The 
consists of library requirements translated Into 
specifications from which programmers develop program 
specifications. It contains, for each screen format or printed 
output, a sample format, the data elements contained on ft, and a 
set of processing rules that explicitly define line and column 
positions for display and printing, editing rules for input 
screens, etc. The system book also contains, for each system 
file, the data elements contained In the file and processing 
™ for Input, update, and searching. Processing rules for the 
editing of Inputs and printed outputs are written In BALLOTS data 
eiement notation CBDEN) (see section 3,5). Library staff also 

BALLOTS analysts on the requirements contained in 
cne system book. The system book was reviewed by both the 
l!b r ary sta-F-F and the BALLOTS programmers for accuracy and 
feasibility. Sample pages from the system book are also 
Included In Appendix B. 



0 of ana1 V sIs efforts during the year was a 
sophisticated bibliographic file organization, capable of 
managing the complex records of materials In process, yet easy 

w^P? h ?iwu ary V se * I hre « major factors influenced this 
work. (1) the need In technical processing (particularly In 
automatic claiming) for being able to keep track of Individual 
physical Items; (2) the availability of the analyzer and the 

bv r sPN!F? V «J^ d l n T?! ec 5 Sf 1 ? E ? <k> > aod < 3) th ® development 
by SPIRES staff of a file definition language. 

Pro ®® ss , Fn ® <IPF> Is a prime example of this file 
F?f,1rl s Jf uctura] levels of the I PF are shown In 

u!?VT e .1 - b,b1 lographlc structure contains the full 

1 £ or , the *'*’•. The library structure contains 
library-specific data (such as a varying call number) for any 

library that Is ordering or holding that title. The acquisition 
conta |. ns data about a specific order by the library for 
rhf N ae f°untlng data, requester Information, etc. 
T5* structure contains control Information for each physical 

item ordered, such as date of order, receipt, claim or 

and Invoice data. When the material Is cataloged, 
the acquisition structure Is deleted, and the Item structure Is 

by ? hold,n £ s structure that gives the shelving location 
and copy number of that physical Item. 



1 PF there Is 
title. 



Within any given bibliographic structure In the 
one ibrary structure for each library ordering that 
Within each library structure there Is one acquisition structure 
I?*.'.*?.? °:i er p aced b * that library. Within each acquisition 

on 5 tem str ueture for each physical Item 
represented In the order. 
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BIBLIOGRAPHIC STRUCTURE 




Figure l. In Process File Structure Levels 



A command language syntax was developed that would enable a 
terminal operator to create a number of Item structures through a 
single Input string. For example. If an acquisition operator 
were to Input the string "3e (volume 1, part A; volume 2; volume 
3, part A-C; volume 4-6), M the following 24 Item structures would 
result: 



volume 


1, 


part 


A 


(copy 


1) 


vol ume 


1, 


part 


A 


(copy 


2) 


vol ume 


1, 


part 


A 


(copy 


3) 


vol ume 


2 






(copy 


1) 


vol ume 


2 






(copy 


2) 


vol ume 


2 






(copy 


3) 


vol ume 


3, 


part 


A 


(copy 


1) 


vol ume 


3, 


part 


A 


(copy 


2) 


vol ume 


3, 


part 


A 


(copy 


3) 


vol ume 


3, 


part 


B 


(copy 


1) 


vo 1 ume 


3, 


part 


B 


(copy 


2) 


volume 


3, 


part 


B 


(copy 


3) 


vol ume 


3, 


part 


C 


(copy 


1) 


vol ume 


3, 


part 


C 


(copy 


2) 


vo 1 ume 


3, 


part 


C 


(copy 


3) 


vol ume 


4 






(copy 


1) 


vol ume 


4 






(copy 


2) 


vol ume 


4 






(copy 


3) 


vol ume 


5 






(copy 


1) 


vol ume 


5 






(copy 


2) 


vol ume 


5 






(copy 


3) 


vol ume 


6 






(copy 


1) 


vo 1 ume 


6 






(copy 


2) 


vol ume 


6 






(copy 


3) 



Rules for such compressed Input strings were wrttten in 
modified BNF (Backus-Naur Form) notation to be passed through the 
SPIRES "action" analyzer. The syntax definition for these rules 
was generalized enough to accommodate variations In the format 
and content of the Input string. For example, the following 
lines are equivalent: 

3 (v 1) 

3 c, ( vol . 1) 

3 c (volume 1) 

3c.(v.l ) , 

This general tzation was done to give the operator as much 
flexibility as possible In composing input strings. 

The presence of Item structures enables the computer to 
deal with Individual I terns tn technical processing. For instance 
If a partial shtpment of a ltbrary order is received, the operate 
uses a matrix-like display screen format to check off the items 
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received. The system then generates a catalog data slip for the 
material received. This slip gives status Information on the 
entire order. During a weekly automatic claiming cycle/ the 
system will also generate a claim notice for the Items ordered 
but not received. 



2,3 CONVERSION TO THE MODULAR APPROACH 

A reduction In available external funding necessitated an 
alternate development scheme for achieving the project's 
goals --modular Implementation. In this approach/ functional 
modules that cut across major subsystems are developed first and 
Implemented sequentially. For Instance/ acquisition and 
cataloging both need to use MARC data — therefore/ by Implementing 
a MARC utilization module/ It is possible to spread system 
benefits throughout the library almost at one©/ without delaying 
the next subsystem — catalog! ng--unt 1 1 completion of the first/ 
and without the relatively greater complexities of overlapping 
two major subsystems, (The MARC module also offers the advantage 
of more immediate benefit to potential members of the CLAN 
network.) Additionally/ because a module cuts across many 
functional areas, a wide base of users Is exposed to automation 
very quickly/ and experience gained In the operation of the first 
modules can be applied to the later ones. 

The documentation required for the modules can be derived 
almost wholly from the process and system books that had been 
prepared for the origtnal bibliographic services design. The 
module documentation Is organized In much the same way as the 
full system documentation/ using the same components. 

The eight general features enumerated In section 2.1 have 
been embodied In a series of modules that may be thought of as 
sets of services providing progressively expanding service for a 
widening variety of library material. There are 11 modules; they 
are described below In the order In which they will be 
Implemented, The detailed requirements for the first module have 
been completed/ documented/ approved by the Stanford Library# and 
are In the process of being approved by each CLAN library, 

1, BALLOTS-MARC . The library material processed by the 
MARC module Is English-language monograph material appearing on 
weekly MARC tapes, (The restriction to English-language material 
Is a consequence of the current scope of MARC; all roman alphabet 
languages are supported by this module.) The file In this module 
Is an on-line MARC file of the most recent 6 to 12 months of MARC 
records. The file Is essentially read-only except for the 
addition of usage and date codes for records processed by users. 
The actual size of the on-line file wtll depend on the 
requirements of the network libraries balanced against file 
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storage costs. Purchase orders, process forms for technical 
processing files, catalog card sets, and spine labels will be 
produced on request for any titles In the MARC file. t . Sn.^^the 
weekly searches to match user requests with new additions to the 
file will be available through a standing search feature. In 
this first module no permanent on-line records will be maintained 
during technical processing other than the full MARC record and 
Its usage status and date codes, although a tape copy of the 
records for each book cataloged will be retained for later use. 
Such on-line record keeping will appear In 

This module will process approximately 55 percent of Stanford s 
acquisitions and 26 percent of Its cataloging. The percentage _ of 
support to CLAN processing Is slightly larger than the Stanford 
figures In this and later modules. The programming of the 
BALLOTS-MARC module is being accomplished with Stanford s own 
financial resources. 

2. MARC- I PF (In Process File). This module adds an I PF and 
additional printed outputs such as claim and cancellation 

noi wh£n requested by library staff. Only MARC material Is 
handled) when a record Is found In MARC It Is transferred to the 
I pp and Is retained there as an updateable record throughout 
technical processing. Since the record will not be purged from 
the I PF until modules 5 and 6 have been Implemented, the f lie 
will represent all titles ordered and cataloged by the library 
uslnetha automated system. A record In MARC-IPF can be used 
again If additional copies of a book are ordered. 

3. Purchase Order/Orlgt nal Cataloging. No new file Is 
added with this module, but the use of the IPF file is expanded 
considerably. Also, Title II Slip and National Program for 
Acquisition and Cataloging (NPAC) notices can be produced. The 
scope of material for which a record is created Is expanded 
considerably. It adds all non-MARC roman alphabet material that 
requires a purchase order In ordering, and any material that 
requires original cataloging. Thus, If a record Is not f ound In 
MARC, a new IPF record Is created on the terminal. This module 
will process an additional 52 percent of acquisitions and 42 
percent of cataloging. Thus services at this point will cover 87 
percent of acquisitions and 68 percent of cataloging. 

4 Non-Purchase Order Material, The scope of material 
added to the IPF Is expanded to Include non-MARC non-purchase- 
order material recel pt— gl f t, exchange, approval, and blanket 
orders. In addition, an invoice claiming feature Is included to 
Inform the Acquisition Department of material for which ”° 

Invoice has been received within thirty days. This module will 
process an additional 7 percent of acquisitions and 6 percent of 
cataloging. Modules 1 through 4 will process a total of 94 
percent of acquisitions and 74 percent of cataloging. 
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5, Catalog Data File, This module Involves building the 
on-1 I ne Catalog Data File* Since the Implementation of module 1, 
BALLOTS will have saved bibliographic Information, and this data 
will be used to create the CDF, From this point on, all catalog 
records will enter the CDF after the record for a given title Is 
no longer required In the IFF. As the CDF grows. It will become 
an Increasingly valuable reference tool for acquisition, 
cataloging, and patrons' use, 

6, Inventory File, Machine-readable bibliographic and 
holdings records already exist for all 60,000 titles now In the 
Meyer Undergraduate Library, In this module, these records will 
be converted to BALLOTS format and used to build an on-line Meyer 
Inventory File (INV). At this point, Meyer cataloging processing 
will work directly with the on-line file. This file will be used 
later on for reference and for the patrons' access to the 
complete holdings of the undergraduate library. Other libraries 
with the entire collection In machine-readable form can be 
handled In a similar manner, 

7, Book Catalog. This module can be used to create any 
book catalog done In the Stanford format. At Stanford It will 
allow the Meyer Book Catalog to be produced directly from the INV 
without going through the punched card process presently used. 

8, Automatic Claiming and Cancelling. This module adds 
programs to review IFF records automatically, to determine If 
ordered material Is overdue. Material may be claimed several 
times and finally cancelled If the dealer does not respond. The 
Acquisition Department may override a scheduled claim or a 
cancel latlon, 

9, Circulation, This module Is designed to handle the 
complexities of the research library circulation system. Using 
data from the Inventory File, a Meyer Library self-service 
circulation system will be Implemented first. Including charging, 
discharging. Initial check-in, circulation searching, recall, 
holds, overdue processing, fine handling, and fine payments. 

10, Standing Order and Out-of-Prlnt Desiderata, The 
capability of establishing standing orders (SO) and receiving the 
non-serial materials arriving with SO's will be added with this 
module. In addition, out-of-print Items (OP) will be added to 
the IPF, and search and quote letters produced for OP dealers. 

If an OP Item can be procured. It can be ordered using the record 
already In the IPF, 

11, Reserve, This module adds reserve book ordering and 
processing for users. It will be added to the services offered 
to Meyer staff through the use of the INV and IPF, 
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Although modules 6, 7, 9, and 11 will ^Implemented first 
at Stanford's Meyer Undergraduate LI Jrary, each module Library 
general Izable and Its application not limited to Meyer Library, 

Modules are not dependent on size of 1 I brary "'J l ?®y and 

employed In small college libraries, research libraries, and 

university branch libraries. 

No module will be released for use at a member II brary until 
It has been In heavy production use at Stanford for a f 
eight-month period. This Is done In order to Insure reliable 
IpIratuISal use of each module prior to Installation In a network 

library. 

Module development and Implementation are ro^ect 6 ** 
In chapter 4, as these have been the major concerns of Project 
BALLOTS In the time following the reporting period. 



2,4 



DEVELOPMENT OF BIBLIOGRAPHIC OPERATIONS ON A VIDEO TERMINAL 



ph 1 1 osophy for 



This section summarizes the project's design 
on-line Interaction between the operator and an automa 
bibliographic system via a video terminal. It Includes a 

discussion of the development of CRT terml nal /^^"the"? t nal 
definition of protocols and a command language, and the flna 

choice of a CRT terminal. 



the 



2.4.1 Background 



terminal s 
equ I pment 



Early In BALLOTS I, work was begun to Identify CRT 
suitable for the user-system Interface. Unfortuna tely, 
of sufficient reliability and economy that also met the 
functional requl rements of a bibliographic 

appear on the market as a production unit during the lifetime or 
BALLOTS 1 Various attempts were made to use off-the-shelf CRT 

terminal I; bu? none could meet the J " 1 1 Flna?"i Report 
account of this early work appears In the BALLOTS I Final Report. 
Although these Investigations did not yield a suitable 
terminal, they did provide Important background that later 
actl vi ty bul 1 t on. 

By August 1970, system programming had prog , ,° a S e ut 
point where It was mandatory to think In specific detail ^® u th 
the way bibliographic data would pass back and forth between th 
o«r«or ini th. system. Since no CRT terminal had yet been f - 
selected, a hypothetical terminal was projected as the basis for 
preliminary design. This procedure subsequent 1 J g r ®JJ* d b J2l c 
extremely valuable. The hypothet cal terminal had the basic 
features that could be found on almost any machine, it was 
rather like a basic IBM 2260: very few functions, only uppercase 
characters, no protected format capabilities, a relatively small 



O 

ERIC 






number of characters dlsplayable at one time, and limited editing 
capabi 1 1 1 1 es . 

2.4.2 T ransf e rab f 1 l ty of Design Experiences 
with Typewriter Terminals 

The design experiences derived from work with the typewriter 
terminals during BALLOTS I were not directly transferable to a 
CRT terminal environment. Communicating via a CRT terminal is 
entirely different from communicating through a typewriter 
terminal. A CRT terminal can transmit an entire block or screen 
of data at one time, a screen on which nearly 2,000 characters 
can be edited and corrected and forwarded as a whole. This 
represents a very different mode of operator-terminal Interaction 
than does the typewriter terminal, which operates in a 
cha racter-by-cha raeter or line-by-line transmission mode. The 
CRT affords no hard copy, and one cannot back up and observe what 
was input five minutes ago. The design staff had many years of 
experience working with typewriter terminals. Now they had to 
acclimate themselves to a new environment. 

2.4.3 Formatted Screens 



Given the model of the hypothetical terminal, the design 
staff began to develop CRT terminal screen formats. The object 
of formatting the display of Information was to ensure that the 
operator would find the data elements consistently presented In 
the same form and position on the screen. Such consistency makes 
it easier for the operator to reeognize various data elements, to 
develop efficient keying procedures, and to Identify errors. 

When a particular element Is always found in the same place on a 
screen, the operator need only check that one location, rather 
than reading the entire screen In order to determine if that 
element Is contained In a given record. Similarly, If the Input 
field for a certain element Is always on the third line, the 
operator can key that data without having to look at the screen 
to position the cursor. 

Since all 120 of the data elements possible in a BALLOTS 
record cannot be displayed at one time. It was necessary to 
divide the data elements Into smaller logical groups. Each group 
represents the raw material for one screen format. Grouping was 
done on the basis of the logical relation of data elements, the 
work flow of the operator, and the length and frequency 
distribution eharacterl st I cs of data element values. 

Certain data elements have meaning only In conjunction with 
other data elements. The format for display of bibliographic 
data, which was modeled on the form of a Library of Congress 
entry, is an example of a format where data elements are 
recognized and Interpreted on the basts of their order and 
position. 
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Some data elements must be grouped together because they are 
all required by the operator and/or the program to carry out a 
specific operation. If an operator Is to make a decision to 
cancel an order, he must first know when the book was ordered, 
who the vendor Is, what type of material It Is, and whether or 
not the library has received any communication from the vendor 
concerning this order. Since the same data element may be 
necessary for several operations, some data elements appear in 
more than one format. For Instance, the purchase order number 
must appear on a screen for cancellation of an order as well as 
on the screen for receipt of material on an order. 

The design team decided that for the data input format, the 
system should prompt the operator with field tags. Experience 
gained in BALLOTS I indicated that it was preferable to have the 
system supply tags and have the operator fill In the blank 
fields, rather than to have the operator supply the tags along 
with the Input data. This method of prompts places the burden of 
remembering tags on the system, and also saves keying. The 
tagging scheme Is based on the data element mnemonics developed 
In BALLOTS I. (These mnemonics are described In the BALLOTS I 
Final Report, section 2,5.1.) 

Data element mnemonics and Input fields were positioned on 
data entry screens by considering operator work flow and the 
frequency of use of each element. In general, fields were 
positioned in the order In which the operator would generally use 
them. However, seldom-used elements were pushed to the bottom 
and to the right of the screen so that the operator would not 
have to key past something he would use only Infrequently, 

The use of prompted mnemonic tags also pointed to the 
desirability of field protection capabilities, A protected field 
Is an area Into which the operator cannot move the cursor and 
therefore cannot write, change, or erase data. The purpose of a 
protected field Is to preserve system-supplied Information (such 
as the format of tags and Input fields), to reduce the 
possibility of entering data Into the wrong field, and to 
facilitate cursor positioning for Input keying. The cursor can 
Jump automatically from the end of one Input field to the 
beginning of the next. Tab functions can also be used to move 
forward or backward from field to field, 

2.4.4 The Overflow Problem 

The most perplexing problem In format design was caused by 
the wide variation In the length of certain bibliographic data 
elements. For example, an analysis of 500 personal name main 
entries taken from a MARC tape showed a minimum length of 6 
characters and a maximum length of 53. The mean length was 
21.74, and 90 percent of the lengths were less than 31 
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characters. A similar analysis of title statements showed a 
mlmlnum of 4, a maximum of 191, and a mean l»n*th i_„. 
characters. Over 90 percent were less than 75 characters long. 

Given the limited amount of space available on a CRT screen 
It Is not at all efficient to define Input fields the s* 2 ® 
maximum length of widely varying data elements. Most of the time 
a format would be filled with unneeded blanks, fewer data 
elements could be grouped Into each format, and therefore * h ® 
operator would have to use many more formats to carry out a given 

function. 

In working with the hypothetical terminal. It " a * concluded 
that extremely variable data element values should be handled by 
a combination of fixed-length fields and an overflow area. The 
overflow area might possibly be at the bottom of the format, or 
It might be a separate format. The fixed-length fields were 
designed to accomodate 80 to 90 percent of the occurrences of 
such an element. This was a cumbersome prospect for both the 
programmer and the operator • 

It became apparent that the only satisfactory solution to 
the overflow problem was to provide expandable fields for these 
troublesome data elements. It was essential that this expansion 
take place without sacrificing format protection. And I t was 
desirable that the necessity for expansion be detected and take 
place automatically, without any special Intervention on the 
operator's part. 

2.4,5 The Role of Data Element Statistical Analysis 
in CRT Screen Design 

In order to group data elements within protected formats, it 
was necessary to have specific information about the behavior of 
those elements, both In terms of size and occurrence. JJe range 
of size of each element affected the size of the Input field, and 
the relative occurrence of elements affected their ordering 
within a format. 

Both the Library of Congress and Columbia University had 
performed extensive analyses of MARC data to determine the 
frequency of occurrence of certain data elements and graphic 
characters, as well as the average lengths of data elements <5, 
6>, However, to design a screen format for display of 
bibliographic records BALLOTS required more Information than just 
average length. Therefore, a statistical program was written to 
learn the distribution of length of bibliographic data elements. 
The purpose of this study was to determine how best to deal with 
the limitations of terminal hardware requiring fixed-length data 
fields, as well as to aid In file design. A program was written 
to profile the distribution and length of each data element In 
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Library's maeh I ne- readable In Process 



MARC records and In the 

File ( I PF), prepared during the operation of BALLOTS I . This 

ln?oli:elI?LO?S R ?Me d h uMHr eCO J dS that haVe bee " tr.MfoSld 

nt® the BALLOTS flle-buIldlng format. 1 The program accepts an 
Input parameter specifying the mnemonic of the data element to 
analyzed It analyzes and tabulates the length of the dlta 

prfnted for^hi/df?!^ * i The following summary Information Is 
printed for the data element In the batch of records examined: 



be 



Number of records examined 
Number of occurrences of data element 
Number of entries with no occurrence of data el 
Number of entries with multiple occurrences of 
data element 



ement 



For each data element, the following Information Is tabulated: 

Length 
I ncl dence 
Incidence sum 
Incidence percentile 

For each data element, the following statistics are calculated: 

Minimum length 
Maximum length 
Mean length 
Variance 

Standard deviation 

Skew 

Kurtos I s 



As an example. In the MARC tapes dated August 13, 1970 and 
October 1 , 1970, the following Information was obtained ?or 

to a MAR? a tai e ToS): MEPN (Ma,n E " try ' Personal equivalent 



Date 8/13/70 

Length for Incidence 
percentile of 90 or 31 
greater 

Number of records 
examined 500 



10/1/70 
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500 



In checking the 1 PF for the data element VSP (Special 

records* °90 MrwSt^? d ?£ 1 10 J oecurr ® nce s were found among 700 
records. 90 percent of the Instances were accommodated In four 



characters; the next length, 12, occurred only twice; length 36 
occurred twice; and six other lengths ranging from 13 to 59 
characters occurred only once each. Appendix C contains examples 
of the output of these programs. The output from this 
statistical program was Influential In arriving at the BALLOTS 
file and screen design. 

2.4.6 Practical Experience 

While still designing with the hypothetical terminal, the 
design staff examined the Sanders 720. CRT terminal that was being 
used at Stanford's Administrative Data Processing Center, This 
CRT terminal did not meet project requirements on a number of 
grounds ; most notably. It did not have an upper/ 1 owe r~ case 
character set. However, It did provide format protection and 
give the designers concrete experience* Various screen ‘Formats 
were built and displayed to the development staff and to 
librarians. Feedback revealed problems and suggestions for 
changes. 

During this period, the design staff took advantage of other 
opportunities to work with various CRT units. Formats were set 
up and altered to take advantage of a particular feature or to 
get around a particular problem Inherent In each different 
terminal. Library staff members worked at the terminals to 
determine what kinds of errors might be made If data were 
organized In a certain way, or what mistakes could be avoided by 
a different organization of the data. 

This experimentation facilitated the move from a general to 
a more specific set of terminal requirements. Some of the Ideas 
originally developed for the hypothetical terminal were found 
completely untenable when a real terminal was available. For 
example, the first solution to the overflow problem (leaving 
blank lines at the foot of the screen) turned out to be extremely 
difficult to use. Some of the visual organization of data that 
had looked fine on paper was unsatisfactory on a screen which 
lacked the niceties of grid lines to Illustrate columns and rows* 
Operators found It very difficult to orient their eyes to such a 
screen. Also, when a cursor became available, the problems 
Inherent In moving It about from one position to another required 
the rearrangement of some fields so that they were In more 
efficient positions or required less cursor movement* 

2.4.7 Development of Protocols and Commands 

To carry out a given function, such as ordering a book, the 
operator must execute a prescribed set of optional and required 
actions Involving a specific set of screen formats. For example, 
the operator must first determine whether or not the book Is 
already on order. His first activity Is searching. That might 



be followed by the use of a second screen format for displaying 
the search results. As a third step he might wish to amend 
existing bibliographic data. A fourth step requires the addition 
of data elements needed for acquisition operations, e.g. vendor, 
purchase order number, requester, etc. Finally the operator must 
signal the system that the record Is complete and ready for final 
machine editing before It Is entered Into the data base. The 
order and Interrelationship of these actions should be designed 
to provide the operator with as much flexibility as possible. 

This order and relationship must also be clearly defined so as to 
ensure completion of the function being carried out. 

The map of legal paths through a function Is called a 
protocol. The term "protocol" Is used here In a larger sense 
than usual. It Is common to talk about communication protocols 
between the terminal and the computer that cover polling 
strategies. Interruptions, and data communication commands such 
as "request for transmit," "negative acknowledge," and the like. 
However, the design staff felt It Important to think in terms of 
a higher level of protocol that included the operator's actions. 
From the project's viewpoint, the most important part of the 
entire communication chain Is what the operator wants to do. 

The objectives In designing a protocol are to optimize the 
normal sequence of actions, to enable the operator to deal with 
any exceptional situations that might arise, and to disable all 
actions that are extraneous or detrimental to a given function. 
All possible paths through a function are mapped so that one 
always knows the status of each piece of data at any given 
moment; so that It can be made clear to the operator which 
element of the system Is In control at any point In time. For 
example. If the operator wishes to correct an error, he needs to 
know the exact status of the data in question, whether 
corrections can be done directly by using the editing features of 
the terminal, or whether the Information has already become part 
of the permanent data base and therefore requires a more 
elaborate correction procedure. The system Is designed to make 
It as evident as possible what can, cannot, should, and should 
not be done at a particular point In a protocol. The operator 
should not have to waste time trying to decode the status of his 
data. 



While the protocols were being defined, a command language 
was formulated to drive the system through the protocols. As the 
operator issues various commands, he chooses one of the many 
possible paths through a protocol and satisfies the requirements 
of that protocol. The command language provides the direct means 
by which the operator instructs the system as to hts wishes and 
Intentions. The protocols by themselves are passive models; ft 
is the command language that initiates action. 



The operator Is prompted with the commands for the main 
line/ the most common route ;h rough a protocol, as a default 
option. Each screen format contains a command field In which the 
system supplies the command verb that will produce the next step 
In the main line of that protocol. Thus the operator does not 
need to take any special actions to deal with the usual cases. 

The command prompts are a function of the protocol, and are 
Independent of the particular screen format In which they appear. 
The same format may appear for several different protocols. For 
example, the format for Input of basic bibliographic Information 
Is needed to produce a purchase order and also to produce a set 
of catalog cards. In other cases a format that Is required In 
the main line of one protocol may be an optional branch In 
another. 

The operator uses the command language to tell the system 
which function he wishes to use, e.g. ordering, receiving, 
original cataloging, reserve processing, etc. The system then 
enters the operator In the protocol specifically designed for the 
function he has requested. This enables the operator to 
accomplish his particular purpose without having to request over 
and over again the facilities he will require on a routine basis. 
The protocol also serves to deny to the operator formats and 
command actions that are Inappropriate to his function. 

The command language Is also the mechanism that allows the 
operator to Instruct the system to take one of the options In a 
protocol. When the operator needs to depart from the main line, 
he simply overwrites the prompted command with some other 
command. For example: If an operator Is using a series of 
formats to Input both bibliographic and ordering data, and 
realizes at the end of the protocol that something was wrong with 
the bib! tographlc data he has already entered, he can. In effect, 
tell the system: "I have completed the ordering data and It Is 
correct; but before adding this record to the file, I need to 
back up and correct bibiographic data input on a previous format 
In this protocol." To do this, the operator simply overwrites 
the prompted command that would enter the record Into the file, 
and replaces It with a command Instructing the system to 
redisplay the format containing the bibliographic data he Input 
earlier In the protocol. Command options such as this not only 
ensure that the operator can handle all situations; they 
eliminate the need to re-key any data other than that which Is In 
error. 

The command language was developed with the aid of a BNF 
analyzer program that checked all command combinations for 
internal logical Inconsistencies. The staff also crosschecked 
the BALLOTS command language with other command languages in use 
at Stanford for inconsistencies between languages. Thus, as a 
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user moves from one system to another# he will not be confronted 
by a situation where the same command verb Is used to mean 
different things In different systems# or where different 
commands are used to mean the same thing* 

2,4*8 Terminal Hardware Evaluation and Selection 

Armed with the above design experience# the BALLOTS staff was 
prepared to make an Intelligent and thorough analysis of terminal 
equipment. Therefore# early In 1971 they began an Intensive 
review of all available CRT terminals that seemed likely to meet 
project requirements. 

Eight major factors governed the choice of the CRT terminal 
for BALLOTS. These# or analogous constraints# are likely to be 
present In any project. They were as follows: 

1. The Host Computer 

The terminal had to be compatible with the hardware and 
software environment of the Campus Facility s IBM 360/67 
and the front-end PDP-11 used to serve CRT terminals. 



2 . General I ty 

The terminal had to be useful for other applications In 
the academic community served by the Stanford Computation 
Center. 

3. Data Communications Mode 

The terminal had to support asynchronous# block mode 
communication at 9#600 baud. Asynchronous transmission was 
required to accommodate the Campus Facility's locally 
produced modems# which had been obtained to eliminate 
the rental cost of equivalent units from common carriers. 

The requirement for block transmission at 9#u00 baud was 
based on efficient use of machine resources and existing 
commun I cat I on II nes , 

4. Character Set 

Because the data base and all printed outputs were to be 
upper and lower-case# the terminal had to have such a 
character set. It Is Important to note here that a 
decision was made by the Catalog Department of the 
Stanford Libraries to do without diacritical marks 
and other special characters. It was felt that the 
additional cost of keying# displaying# and printing 
the special characters# as well as of their Inclusion In the 
terminal equipment# did not balance against their added 
utility and benefit. 
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5, Full Editing Capabilities 

The terminal had to have full cursor controls. Including: 
up, down, left, right, home, and tabs. It also had to have 
character Insert, delete, and overstrike, and line Insert 
and delete. 

6, Screen Capacity 

The terminal had to be able to display at least 1,000 
good quality characters at one time. A capacity of 
2,000 characters was preferred, 

7, Format Protection 

The terminal had to have field protection capability, 
and some method of field expansion to handle overflow. 

8, Practicality 

The terminal had to be available at an affordable price, 
reliable, made by an experienced manuf acturer, and 
supported by a good service organization. 

Two developments In the technology of terminal manufacture 
provided choices In 1970-71 that were not available when Project 
BALLOTS began. One of these was the emergence from the research 
and development stages into reliable production of MOS/LSI (Metal 
Oxide SI 1 Icon/Large-Scale Integration) technology'. This new 
technology Increased equipment reliability and offered the 
possibility of much more sophisticated terminals at reasonable 
cost, owing to the very great compaction of components made 
possible. The second development was a direct consequence of the 
first* availability of the "smart” terminal containing a 
programmable processor. 

The advent of programmable terminals was particularly 
significant for BALLOTS. A blbHographle application Is quite 
different from the business applications for which hardwired 
terminals are usually designed. The programmable terminal 
offered the posslbt 1 Ity of tailoring and optimizing the 
operational functions of the terminal for our particular 
application. Most Important, the programmable terminal offered a 
sound solution to the overflow and field expansion problems 
discussed above. 

The choice of terminal was narrowed to three units: the 
Splras Systems’ I rascope model TE (now designated model LTE), the 
Four Phase Systems’ System IV/70, and the Sanders Associates' PDS 
(800 series). 
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The Spfras Irascope model TE had been developed In close 
collaboration with the Ohio College Library Center specifically 
for an on-line bibliographic system. Therefore the project gave 
this terminal special attention even though It was not a 
programmable unit. The review of this terminal produced much 
valuable Information and many good Ideas, However, the Irascope 
did not meet a number of project requ I rements . It was a highly 
specialized unit that would not have been of general use to the 
Stanford community. Although It offered block transmission. It 
did so only at 2,400 baud synchronous, rather than 9,600 baud 
asynchronous * Modifications to change the I/O would have raised 
the price significantly. And the fact that Splras Systems was a 
small eastern manufacturer with few units In the western United 
States and no service organization of Its own did not bode well 
for maintenance service. 

The Four Phase IV/70 was attractive by virtue of Its 
programmable processor and the fact that It Is manufactured In 
the San Francisco Bay area. Although this might have been an 
acceptable unit for the BALLOTS application. It suffered from two 
limitations. First, It was able to display only 1,152 characters 
at one time. Second, It was available only In a clustered 
configuration. This meant that, although It was economically 
viable for a large user with many terminals. It was prohibitively 
expensive for the user with only one or two terminals. It was 
felt that this limitation would make the terminal Impractical for 
potential CLAN members. 



The final choice was the Sanders 800 series. It met all 
project specifications, and Its programmabl e features appeared to 
make It the most flexible device for our application. 

Furthermore, It was easy to Intermix clustered and stand-alone 
units, a consideration of economic significance for use In 
various-sized libraries. It was the only unit that accommodated 
data transmission via the same type of cable required for cable 
TV, (Because other projects at Stanford were Interested In cable 
TV for transmitting data. It was considered highly desirable to 
have equipment accommodating a service that could later prove of 
Importance to the library). Finally, at the time the comparative 
analysis was performed, the Sanders was the least expensive unit. 
Later, changes were made that increased the cost of the Sanders 
terminal, and its cost advantage over the Four Phase IV/70 
evaporated. However, both these units were still less expensive 
than the Irascope TE. Finally, Sanders Associates was the 
largest and most experienced of the three manufacturers, and they 
had built up a service organization that was among the largest In 
the Industry. 
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2,4.9 Real and Imaginary Terminals 

In conclusion, there were two phases to the CRT screen 
design. First was the initial approach to the subject, which 
Involved solving certain general problems. This phase can be 
conducted on paper with a hypothetical terminal. Second was the 
tailoring of the basic approach to a specific physical 
environment, to a specific terminal. As soon as a terminal had 
been selected, the criteria for designing screen formats could be 
totally formalized, a step that could not be taken beforehand. 

For example, different terminals not only have different 
character sets, they also have different numbers of characters on 
each line and different numbers of lines on the screen. 

The preliminary design experience on the hypothetical 
terminal was most valuable. Had the terminal been selected 
before any design work had been done, the choice would have had 
to be made on much less specific and less mature requirements. 

And had the staff begun designing on a real terminal rather than 
a hypothetical one, the same learning experience would still have 
been required before It could be decided how to use that 
terminal. Actually, transfer of the design work done for the 
Sanders 720 to the Sanders 800 series was primarily a refinement. 
There were no basic changes. With the new device, some of the 
problems Inherent In the earlier terminal could be solved 
relatively easily. No situation arose that required the design 
staff to backtrack and go off In a completely new direction. 
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CHAPTER 3 



ANALYTIC STUDIES AND STANDARDS 



i /'p 

This chapter presents several analytic studies made/ 
standards created/ and and decisions taken to support the design 
and Implementation of BALLOTS 11. The studies and standards 
Incorporated In the text are as follows: Video Terminal Support 
for SPIRES and BALLOTS on Stanford's IBM 360/67; BALLOTS Data 
Element Notation; Video Terminal Evaluation; Video Terminal 
Screen Standard; BALLOTS Command Language; Coding and Description 
Standards for PL360; an ASIS 1971 Conference paper on on-line 
library network planning. In addition/ cost studies conducted 
are described. 



3.1 HOST COMPUTER ANALYSIS 

A study was first made to determine the feasibility of a 
computer facility dedicated solely to library automation and 
other data file services; the tdea was rejected because of the 
cost Involved. 

Since It was not found financially feasible for Stanford to 
dedicate a computer to library automation/ an Intensive study was 
made during the reporting period to determine the most 
appropriate available computer to support the BALLOTS production 
system. The two most promising computers were found to be the 
Administrative Computing Facility's IBM 360/40 and the Stanford 
Computation Center Campus Facility's IBM 360/67. 

Two separate studies were conducted by the BALLOTS team with 
the programming teams from each facility. Preliminary designs 
were developed and an estimate made of the modifications and 
extensions of existing software required to support BALLOTS. 

3.1.1 Administrative Computing Facility 

The Administrative Computing Facility (ACF ) was operating a 
360/40 for use by the administrative sector of the University, 
This Included jobs for the Registrar/ the personnel and payroll 
departments/ and the alumni records. A project was underway In 
the ACF programming area to design and Implement an on-1 [ne 
administrative computing system using video terminals. The 
development activity had been about half completed at the time 
BALLOTS began Investigating the use of the ACF computer. The 
video terminal used by the ACF development team was a Sanders 
720/ which had the hardwired capability of protected fields but 
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not of field expansion. Since most of the administrative work 
could be carried out using the 720 CRT screen format with a file 
design that Included a variable number of fixed-length data 
elements, there was no critical need for variable-length fields 
either on the CRT screens or In the file. 

The BALLOTS programming team worked with the ACF programmers 
to determine the Impact on both the ACF and the BALLOTS 
development schedules and Intentions If the BALLOTS programming 
and production operations were carried out on the ACF computer. 
This study was conducted over a six-month period. One of the 
major portions of the study was an ACF review of the BALLOTS 
requirements, workloads, and development schedule, and a similar 
BALLOTS review of the ACF activities. After this was completed, 
the two teams produced a combined development task chart, 
describing over 250 tasks, that covered all of the current and 
planned activities for both ACF and BALLOTS, Merging the tasks 
on the same chart required an estimate of the amount of addi- 
tional work that the ACF systems programmers would have to do to 
accommodate the BALLOTS requirements. 

The study showed that the software changes necessary to 
support var I abl e- 1 ength fields In file storage and on CRT 
terminals would require completely redesigning the ACF’s file 
services software and also redesigning the terminal handler 
software. Changes to accommodate the additional number of 
terminals and the added transaction load would cause further 
software changes In the system. From the BALLOTS standpoint, 
more work would be required of programmers and analysts to 
produce a system of less benefit to the user than had been 
planned. Certain necessary aspects of the BALLOTS des I gn--such 
as the overflow problem (see section 2.4.4) — were never 
satisfactorily accounted for In the ACF study. The cumulative 
Impact of all these changes and compromises would have been a 
major change In the direction of BALLOTS development as well as 
In the schedule of the facility. It was therefore decided that 
Project/ BALLOTS should not be supported on the Administrative 
Computing Fact 1 I ty 360/40. 

3.1.2 Campus Facility 

During 1969 and early 1970, the Campus Facility machine was 
close to saturation. The Installation software at that time was 
workable and efficient, but had not yet been fully optimized. 
Furthermore, there was a heavy batch workload. For this reason 
BALLOTS and SPIRES began by carefully Investigating the ACF, But 
while the two projects were Investigating the ACF environment, 
two changes took place In the Campus Facility; a gain In CPU 
cycle availability due to substantial software optimization, and 
a decrease In the overall workload. In the past year, 
reliability on the 360/67 has increased to the point where uptime 
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Is around 96 percent. Throughput In the high-speed batch 
partition has Improved 40 percent. For example, the execution 
time for an average Job has been reduced from 4,3 seconds to 2,2 
seconds and the minimum Job cost has been reduced from fifty 
cents to twenty-five cents. Text-editor (WYLBUR) throughput has 
Increased 100 percent — I.e., It has doubled, effectively cutting 
costs to the user by 50 percent. These Improvements to the 
operation of the 360/67 resulted In an average machine cycle 
availability of 30 percent. 

Thus, the Investigation of the Campus Facility showed 
that It could offer strong support, experience In developing 
time-sharing and virtual memory software, and on-line Interactive 
systems that Included text editing and compllaton. This software 
had been available for several years via typewriter terminals 
(primarily IBM 2741); 88 of 130 typewriter terminals on and off 
campus could be logged on at the same time. Software support for 
video terminals was not available, however, nor had a standard 
campus video terminal been selected. 

3,1,3 Video Terminal Support for SPIRES and BALLOTS on 
the IBM 360/67 

The preliminary study for developing and Implementing 
BALLOTS at the Campus Facility showed that the additional 
transaction load from library automation could be absorbed 
without seriously affecting the existing software or service to 
users. The major addition required to the software would be 
support for CRT terminals. The Campus Facility provides services 
to faculty, students, and staff; and therefore must make all 
services as widely usable as possible. The CRT terminal chosen 
for library automation would also be available as a general 
campus CRT device, providing all the services of the Campus 
Facility, In addition to the powerful and flexible Sanders 
terminal chosen for BALLOTS, the Campus Facility elected to 
support a more modest (and much less expensive) CRT terminal, the 
Hazelttne 2000, The Campus Facility produced the following 
preliminary design report describing support for video terminals. 

* * * DOCUMENT FOLLOWS * * * 



1, BACKGROUND 

Discussion began In January 1971 between the BALLOTS and SPIRES 
technical staff and the staff of the Stanford Computation Center 
Campus Facility (SCCCF) on CRT terminal support for the SPIRES/BALLOTS 
system. Several alternative designs were discussed. Each had 
Its own effect on present SCCCF software, on core requirements, on 
overall system performance, on BALLOTS II development schedules, 
on reliability, and on cost. 




34 




2, ALTERNATIVES 



Each alternative, with a discussion of Its merits and 
disadvantages. Is given below, 

a. Via a 2701 Into MILTEN 

MILTEN, the communications subsystem, operates 
In an Interrupt mode to support up to 88 IBM 2741 
typewriter terminals. With this arrangement, 
a buffer pool consisting of 88 160-character 
buffers and associated control blocks must be 
reserved. The additional code and buffers to 
support thirty to forty CRT terminals 
(assuming 1,000-character screens), using 
either an Interrupt or a polling discipline, 
would require a prohibitive amount of core. 

Such core could be taken from resident core in 
the nucleus, from execution pages within 
ORVYL, or from the large batch partition. All 
of these alternatives are considered unaccept- 
able because of their effects on overall system 
performance. Furthermore, the Ml LTEN/WYLBUR 
and MILTEN/ORVYL Interfaces now existing would 
be disturbed, thus requiring critical areas 
within the system to be redesigned and re- 
coded. 

b. Via the existing PDP-9 into ORVYL 

ORVYL, the time-sharing subsystem, now contains 
dev I ce- 1 ndependent code that "talks" to 
a PDP-9 via the multiplexor channel and 
a 2701 Parallel Data Adapter. The PDP-9 contains 
device-dependent code for "foreign" computer 
links, paper tape devices, graphics scope devices, 
and teletypes. These are termed "external devices" 
and can be attached by a 2741 terminal program 
executing out of virtual memory under ORVYL. To 
augment the device-dependent code In the PDP-9 
to support CRT terminals for BALLOTS II would 
either force a user to log on with a 2741 and 
switch to the CRT terminal (unacceptable from an economic 
standpoint), or force the BALLOTS II development 
staff to create a task-dispatching mechanism to sit 
underneath the one existing In ORVYL (thus seriously 
affecting the schedule). In addition, the reliability 
factor in the PDP— 9 would be considerably degraded 
because of the unknown behavior of the various 
other external devices. It is also uncertain 
whether or not the PDP-9 would be capable of 
carrying the expected load. 
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c. Via a dedicated small computer Into MILTEN and ORVYL 

Wlth a dedicated small computer providing 
buffering# line handling, error re-try, etc,. 

It Is considered feasible to provide a reliable 
Interface between as many as 32 CRT terminals and 
the SCCCF 560/67 with a minimum of perturbation to 
existing system software. The CRT user may log on 
In 1 I ne-by-1 l ne mode Into MILTEN, with the small 
computer simulating the behavior of a 2741, After 
the user signifies that he wishes to be attached 
to ORVYL, a supervisor call Is Issued that 
commands MILTEN and the small computer to 
place the user In ’’full scope face” mode. 

From that point, all I/O takes place from 
pages of ORVYL execution space rather than 
from the MILTEN buffer pool. The control 
block In the buffer pool merely has a flag 
set, with a pointer to the real buffer In 
the ORVYL partition. Such an approach Is 
expected to require minimal core on the 
360/67 and feasible changes to the existing 
system software. It was therefore chosen 
as the basis for CRT support on the SCCCF 
360/67, 

3. CHOICE OF SMALL COMPUTER 

After conducting a survey, the Small Systems Group at SCC 
reduced the set of possible smal 1 computers to Data General s 
Super Nova, Varlan Data Machines' 6201, and Digital Equipment 
Corporation's PDP-11, From the standpoints of reliability, 
flexibility, and operating characteristics, the PDP-11 stood out 
as the best alternative, especially with regard to Its flexible 
busing scheme. Furthermore, local expertise has been built up 
during the Installation of a front-end PDP-11 at the ACME 
(Medical School) Facility of SCC. 

4, TERMINAL COMMUNICATION 

There are three alternatives for arranging communication 
between the terminals and the PDP-11, They are, (1) dedicated 
lines, (2) mul t {dropped lines, (3) time division multiplexing 
(TDM). In comparing the first two alternatives. It was felt 
that dedicated lines would Increase the user cost beyond 
practical limits. The second alternative — mul tldropped 1 Ines-- 
was recommended as an Interim choice, pending completion of 
a study on the feasibility of TDM, It was not felt that the 
alternative selected would lead to the scrapping of any 
significant amounts of either hardware or software should TDM 
become the accepted approach. There was the further advantage 



of allowing parts of the project unaffected by this decision 
to commence Immediately. The remainder of this memorandum 
therefore addresses Itself to a multldropped sys?lm? 

5. CHOICE OF TERMINALS 

fr. rtrtt .I«°j terfI1,na l S £ hdva L be ® n ehos ©n as standard CRT terminals for 
« - support for the Stanford community and all Its users 
?nnn Ud u? ® f £“ ca |"P us network members. They are the Hazel tine * 
a 2 nT;h” h i Ch a haS ^ een V sed wIth In the Campus Fa2 f ?y, 

(See slctfSnn P^ammabl e terminal? ' 

th -f ifS* i 2 i 4,8 and 3 * 2 for the analysis of CRT terminals 
that led to Sanders as the choice.) s 

6. IMPLEMENTATION SCHEDULE 



The schedule for 
divided Into two s 



for Implementing the front-end system has been 
cages : 



Stage 1 



Deliver and Install all equipment In Pine Hall, 
and when sufficient progress has been ensured/ 

S M n ? er ?.u splay terml nal s will be Installed 
at the Main Library. It Is anticipated that 
programmable terminals will be multldropped to 
reduce communication costs. 



,f m® l ? EC multiplexor Interface becomes 

pd! ^?,T* U/ ? 701 Interface and the 

PDA Itself will be replaced by a DEC-DXX1 Inter- 
face. This will replace a 2701 that has 
rental cost of $12,000 based on a forty* 
period. 



a 

•month 



not 



Stage 2 : Deliver and fnstal 1 at least one Inexpensive CRT 

terminal and Integrate Its operation Into exlst- 

h2 S i?mff e r4 l # , sup Port. This will Include but will 
be limited to operation on the public switched 
telephone network as well as on dedicated clr- 
cuits. The Inexpensive terminals will not be multl- 
dropped. Some economies may be achieved In the 
hardware Interfaces to the PDP-11 If a transmission 
rate less than 9,600 bps Is selected. fS?" aria 
remains to be elaborated. 

7. BILL OF MATERIALS 

A. DEC 



1 PDP-11/20-CA computer with 4k memory 

i vlji i "a 16-bit 1.2 us add-on memory 
1 KW11-A real-time clock 



$11,450 

7,000 

250 



O 
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1 

1 

2 


DD11-A mtg. panel 

DX-11 MPX channel Interface 

KL-11X full duplex line Interfaces 


175 
5# 000 
800 


Total 


$24# 675 


Eng I neer I ng 




1 . 


PDP-11 IBM 2701 PDA Interface 






1 DR11 
Logic 

MI seel 1 aneous 


$ 400 

400 
300 




Subtotal materials 
Labor (seven man-days) 


$ 1#100 
700 




Total 


$ 1# 800 


2. 


Multidrop Interface boxes 






Recel ver/drl vers 
Mi seel 1 aneous 


$ 180 
120 




Subtotal materials 
Labor (one man-day) 


$ 300 

100 




Total 

times four boxes 


$ 400 

x4 




Total 

plus extra receiver/dri ver 
on KL-11 


$ 1# 600 
180 




Total 


$ 1# 780 



Note: Each multidrop Interface box Is capable of driving four 

terminals within one hundred feet of each other. If 
terminals could be thus clustered In the library# the 
cost for multidrop Interfaces would be $400, 

8. SITE FOR THE PDP-11 

The Operations Manager# Campus Facility# sees no problem In 
locating the PDP-11 near the current PDP-9 Installation In Pine 
Hal 1 . 

* * * DOCUMENT ENDS * * * 

Based on the results of this study# a formal decision to 
implement 1 Ibrary automation on the Campus Facility was made and 
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design and programming continued. The next step for the Campus 
Facility Included the specification for ORVYL support of CRT 
terminals, the ordering of the PDP-11, and the building of the 
Interface hardware. It was found that all the deficiencies In 
the plan to Implement at the Adml nstrat l ve Computing Facility 
ware overcome or could be overcome at the Campus Facility, 



3.2 VIDEO TERMINAL EVALUATION 

NOTE: This analysis was based on Information about products 
and prices available as of May 1, 1971, It does not reflect the 
changes in products and costs and the Introduction of new 
products that have occurred since that date. 

* * * DOCUMENT FOLLOWS * * * 

In February 1971, Project BALLOTS began an Intensive search 
for an acceptable CRT terminal to be used In an on-line 
bibliographic application. Requirements (Table 13 were based on 
the conceptions of the BALLOTS staff, experiences of similar 
projects, and the hardware and communications environment of the 
Stanford Computation Center (SCO. The survey of available 
terminals began with a review of technical publ I cat Ions such as 
the Auerbach Data Communications reports. also reviewed were 
articles and advertisements In data processing and library trade 
journals. On the basis of the Information available at that 
time, specific data about the terminals were gathered In Table 
II. 



A preliminary comparison of the terminals (Table II) against 
our requirements (Table I) pointed to six potentially acceptable 
terminals. The most difficult requirement to meet was the one 
for protected format with expandable Input fields. The six 
terminals, and the modifications necessary to make them meet the 
formatting requirements, are listed In Table III. 

After closer examination of the units, this group of six was 
narrowed to a group of three: the Four Phase IV/70, Sanders 804, 
and Splras I rascope TE. The Datapolnt 2200 was rejected because 
It had only a 12-1 Ine by 80-column screen (960 characters) and 
because It did not have adequate keys for cursor control. The 
Delta TelTerm II was rejected because the use of an external 
minicomputer to supplement the terminal's functions was not 
considered desirable while there were questions about the 
reliability of the compute! — terminal combination and the fiscal 
strength of the company. The Imlac PDS-1 was rejected because of 
flicker in the visual Image, especially when more than 1,200 
characters are displayed, and because of higher unit cost. 

The three remaining terminals were compared by function 
(Table IV). Differences In memory size and character set were 
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TABLE ( 

BASIC TERMINAL REQUIREMENTS 



DISPLAY: Minimum 12" diagonal CRT 

Minimum 1000 character display 
Minimum 24 line by 48 column display 
Upper/lower case character set 



KEYBOARD: 

FUNCTIONS: 



Typewriter layout 
(ANSI x 9A9/199B preferred) 

Protected format with expandable Input fields 
Full cursor control 

left 



up 

down 

tab 

home ! 

Full editing capabilities 

character insert 
character delete 
character overstrike 
line Insert 
1 1 ne delete 

COMMUNICATIONS: 9600 baud 

(Asynchronous preferred) 
Block I/O 

Stand alone capabilities 





TABLE I I 





TERMINALS CONSIDERED 


MANUFACTURER 


MODEL 


Beeh I ve 
Cou r l e r 


1 , II, III 


CTC 


Datapoint 2200 
Datapoint 3300 


DEC 


VT05, VT06 


Delta Data 


Tel Term II 


Hazel tine 


2000 


1 BM 


2260, 3270 


1 CL 


7181 


1 m 1 a e 


PDS-1 


1 nf ot on 


Vista 


Lear S 1 eg 1 er 


7700 


Sanders Associates 


720, 800 series 


S p i r as Sy s terns 


1 rascope TE 


Uni Comp 
XDS 


522 



Four Phase 



I V/70 



* 



TABLE I ! ! 



i 



Terminal 

CTC Datapolnt 2200 
Delta Data System Tel Term 

j 

i t 

\ Four Phase IV/70 

' 

imlac PDS-1 
Sanders 800 series 
Splras Irascope TE 



Necessary mod I f S ca t ! ons to moot 
format reou i reman t , — 

Add to manufacturer's 
software for terminal s 
processor. * 

II Run terminal In full duplex 
with external minicomputer 
supplementing terminal 
functions. 

Add to manufacture's soft- 
ware for terminal's processor. 

Add to manufacturer's soft- 
ware for terminal's processor. 

Add to manufacturer ' s soft- 
ware for terminal's processor. 

Specify reprogramming of 
certain ROM's by manufacturer. 






TABLE IV COMPARISON OF TERMINAL CHARACTERISTICS 
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not felt to be significant for our application. Reliability Is 
an unknown factor for all three units. The flexibility of the 
programmable processor and the flexibility of units providing 
both stand-alone and clustered configurations made the Four Phase 
and Sanders terminals more attractive than the Splras unit. The 
Splras unit was also less desirable than the other terminals 
because of Its synchronous transmission and late delivery of 
9,600 baud. The Sanders terminal Is preferable to the Four Phase 
on the basis of display size. And the Sanders Is built by a 
well-known, established company. 

Table V contains a cost comparison of the three terminals. 

No Information Is available on a cost of a Four Phase stand-alone 
unit. The only figure, quoted tentatively, for the Sanders 
cluster was $27,200 for a cluster of eight. Other Sanders prices 
are preliminary. Given these limitations, an evaluation of the 
data In Table V Indicates that: (1) for quantities of one to 
three terminals, a stand-alone unit Is definitely desirable: (2) 
the Splras unit Is significantly more expensive than the other 
two; (3) the Sanders 800 series appears to be slightly less 
expensive than the Four Phase; and (4) the Sanders 804 Is the 
least expensive alternative for our first Installation of four or 
five units. And for our first Installation, the Sanders 804 

al ?? e L also P rov fdes more flexibility than the Four Phase 
iv/70, which Is currently available In a cluster only. 

* !2.. a ^P Ion, the Sanders terminals are engineered to receive 
cable TV signals form coaxial cable. This fact makes these 
terminals more desirable for future campus communication 
developments at Stanford University, and could be an Important 
factor In future research work, 

A comparison of delivery schedules (Table VI) shows the 
Sanders to be somewhat later than the others. However, the 
delivery constraint does not seem to be severe enough to outweigh 
the other advantages of this unit. 

We therefore recommend the Sanders 800 series CRT terminals for 
use In this application, 

* * * DOCUMENT ENDS * * * 



3,3 VIDEO TERMINAL SCREEN STANDARD 



Once the CRT termtnal evaluation had been completed and the 
Sanders 804 terminal had been chosen, the characteristics of the 
terminal as they affected the user, the programmer, and the 
system analysts were documented; from this Information a standard 
was developed. This standard treats (1) the method for line 
overflow when a data element takes up more space than has been 
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TABLE V 




COST COMPARISON 
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allocated on the CRT screen; (2) the location and definition of 
the command line; and (3) the definition and location of error 
messages. 



* * * DOCUMENT FOLLOWS * * * 

Definition and Use of Protected Fields 
INTRODUCTION 

This is a description of the principles of Interaction 
between the library user and on-line portions of the BALLOTS-MARC 
modules, A program called the BALLOTS subprocessor (BSP) will 
control the Input, editing, storage, retrieval, and display of 
data. The user will communicate with the system through a 
Sanders 804 (stand-alone) or 810 (clustered) programmable CRT 
terminal. The input and display of data will be organized within 
formats for ease of use and verification. The operator gives 
directions to the BSP through a command language. These elements 
will be discussed below, 

SYSTEM MODEL 

The following model Is provided as a point of reference for 
the terms and explanations that follow. This Is a conceptual 
model, not a program design. The BALLOTS subprocessor may 
Indeed be organized in a vastly different manner, but the user 
will be able to conceive of operations according to this model. 
The primary purpose of the model Is help Illustrate what 
the elements of the system are supposed to do. How the system 
actually effects the actions described is entirely up to the 
programmer. 

FORMATS AND FRAMES 

A format, or format routine, is a program that serves as an 
Intermediary between the user and the data base. It organizes 
the Interchange of data into logical units and allows the user to 
deal with logical subsets of the data elements that make up a 
single record. The format aids the user by labeling data 
elements and displaying them In a consistent manner. The format 
also edits for accuracy and completeness the data input by the 
user. 

A format consists of a set of format and display rules, 
and a set of 3d 1 1 and storage rules. The first set of rules Is 
used when data Js output to the terminal from the computer. The 
second set is used when data Is Input from the terminal to the 
computer. 



What the operator actually sees on the face of the CRT Is 
called a frame, A frame Is created by the format routine. A 
frame always consists of 24 lines of 80 characters each. The 
format routine takes data from the data base, organizes and 
labels It according to the formatting and display rules, and 
sends It, along with positioning and protection Information, to 
the terminal where It Is stored In the display memory. The 
terminal uses the positioning and protection Information to write 
the frame on the face of the CRT. 

A format routine may create one or more frames before It 
completes Its processing. And the same routine will create a 
different number of frames In different circumstances. This Is 
caused by the fact that although a specific format always deals 
with the same group of data elements, the length of the data 
elements may vary widely from one occurrence to another. 

FIELD EXPANSION 



One of the most Important characteristics of BALLOTS CRT 
screen formats Is the ability to have Input fields of flexible 
length. This function Is carried out by the terminal processor 
without Interrupting the remote CPU. If an Input field extends 
Into position 80, that field may expand In Increments of 
80-posl t Ion lines, one at a time. After position 80 Is filled. 

If the next character Is not a tab or carriage return, which 
would take the cursor to the next field, the terminal program 
will Insert another Input line for the current field. This line 
will be Inserted Immediately below the current line, and 
succeeding lines In the frame will be pushed down one line. The 
last line In the frame will be pushed off the bottom of the 
screen and will be lost from the display memory. But the 
Information displayed In this last line Is not lost from the data 
area of "user scratchpad memory" (USM), When the frame Is 
transmitted, the format routine will rewrite the record In the 
data area to accommodate the inserted lineCs). The format 
routine will then build another frame and send It to the 
terminal. The beginning of this next frame will overlap the last 
two lines of the previous frame. 

If the operator has Input data In the last line and then 
pushes that line off the bottom of the frame, the Input data will 
be lost because It has not been transmitted to the system. 

PROTECTION 

It Is possible to code characters In the display memory so 
that they cannot be altered from the terminal keyboard. A format 
must send Information specifying that certain characters are to 
be protected. In BALLOTS, all positions that are not to be made 
available to the operator for input are designated as protected. 
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When making up a frame from a format, all 
the 24 lines must be accounted for. 



80 positions of each of 



DESCRIBING FORMATS 



To completely define the requirements for 
two things are required. The first is a visual 
display of data on the CRT screen, 
grid form (a sample of this form is 
Appendix B), using as many lines 



as 



i CRT screen format 
model of the 
This is done on a BALLOTS 
included at the end of 
necessary to accommodate the 



group of data elements In the format. . Division and overlap 
between frames Is a flexible matter because of 
expansion. 



possible field 



The second thing necessary to define a format is a set of 
processing rules. These rules specify the relationships between, 
and the rules governing, the data elements Included in the format. 
These rules may also specify special considerations to be 
observed In dividing a record Into frames. 

GENERAL CONSIDERATIONS OF CRT SCREEN FORMAT DESIGN 

1. All frames created by format routines (except search formats) 
will consist of two parts, the header and the body. Search 
frames contain only a header. 

Header 

2. The header occupies the first three 

lines of all frames except search frames. The 
header occupies all 24 lines of a search frame. 

When a record must be divided into more than one 
frame, the header will be repeated at the beginning of 
of each frame. 

Control Field 

3. The- first element of the header is the control 
field. This line contains the Format I.D. In columns 
6-11; File I.D., columns 17-28; Record I.D., columns 
34-42; Function I.D., columns 48-55; Library I.D., columns 
61-67; and operator I.D., columns 73-76, Values for these 
items are always left-justified. An explanation of each of 
these items can be found In the BALLOTS Data 

Elements Notebook <7>. 

Message Field 

4. The message field Is the second element of the 
header. it occupies line 2, positions 1-80. It is 
protected. It is used to display diagnostics 
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concerning the command field and general messages 

from the system. If a message exceeds 

80 characters# It will expand and push down 

succeeding lines. In a search frame the message field may 

be up to 22 lines In length. 

Command Field 

5, The command field Is the third element of the 
header. The command field Is an Input field# 

I.e,# It Is unprotected. It follows the message field 
In all frames but search frames. The command field 
occupies positions 1-79 of line 3, It does not extend Into 
position 80 because the command field Is not allowed to 
expand and push down succeeding lines In non-search frames. In 
search frames the command field begins In position 1 
of the line Immediately following the message field and 
continues to the end of the frame. The command field 
of a search frame may be up to 22 lines In length. 

Body 

6. There are two types of bodies: (1) display bodies 
and (2) Input bodies. Update bodies 

are a form of Input bodies. 

Display Bodies 

7. In display bodies# all lines are 
protected. The operator may Input In the 
command field only. 

8. Common# easily Identified data elements need 
not be labeled In a display body. 

9. Rare data elements# and/or data elements whose 
Identity Is not obvious from their value# 
must be labeled. 

10. In display bodies# textual data should be organized Into 
logical paragraphs, 

11. Short# fixed-length data elements may be organized 
Into multiple columns If desired. Columnar 
alignment should be made on the first character 

of the data element value. All lines containing 
more than one data element should conform to the 
same columnar structure. 

12. Columnar data should be grouped together# not 
mixed with paragraphed data. 
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13, When the same data element, or group of data 
elements, ts Included In several different formats, 
the display position and organization of such 
elements should be consistent across formats. 

Input Bodies 

14, Input bodies may contain two types of entries: 

(1) data element entries, and (2) instruction entries. 

Data Element Entries 

15, Each data element entry contains two parts: 

(1) a label, and (2) an Input field. There are 
two types of labels and two types of input fields. 

Labels 

16, All labels are eight characters long. The first 
two character positions are reserved for the 
display of error codes. The third position 

is blank. The fourth through seventh positions 
are for the data element mnemonic. The eighth 
position is blank. 

17, The first type of label is a "prompted mnemonic" 
label. In this type the format routine provides the 
label. It Is right-justified to position 7 of the label, 
and cannot be altered by the operator. All eight 
positions in this type of label are protected 

for strict Input formats. In update formats, 
the eighth position Is unprotected. The operator may 
Insert an asterisk in this eighth position to signify 
that the element Is being updated, 

18, The second type of label Is an "operator 
supplied mnemonic" label. In this type, 
positions 4-7 of the label are unprotected, 
and the operator Inputs a mnemonic anywhere 

in these positions. Positions 1-3 and 8 are protected. 

In update formats (see 17) position 3 is unprotected to 
allow the operator to Insert an asterisk to signify an 
update • 

19, Entries for data elements that may be multiple 
within a structure (BIBS, AS, IS) must use 
"operator-supplied mnemonic" labels. If the structure 
is multiple but the data element is singular within the 
structure, e.g., MDX in AS, or LOC In IS, prompted mnemonics 
should be used. The program will know how many copies of 
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* * 



the structure are needed to present a given record In a 
given format, ■ 



20, The two types of labels should not appear In the 
same format. 

Input Fields 

21, The two types of Input fields are (1) fixed 
length fields of less than 72 characters, and 
(2) expandable fields, 

Fixed-Length Input Fields 

22, Fixed-length Input fields have a maximum length 
of 71 characters. Since an Input field must 

be preceded by an eight-character label, an Input 
field longer than 71 characters would extend 
Into position 80, Only expandable 
Input fields may use position 80. 



25 



24, 



If a fixed-length Input flelld Is short enough. It Is posslbl 

to Include more than one data element entry In a single line 

This Is permissible If (!) there are at least five spaces 

between the end of each Input field and the 

beginning of the next label, and (2) If all lines 

In a format containing multiple data elements 

conform to the same columnar structure. 

Columnar lines should be grouped together, not 
mixed with single data element lines. 



Expandable Input Fields 



25, For a field to be expandable. It must begin In 
position 9 (Immediately after the label that 

began In position 1) and must extend Into position 80, 
If the 73rd character Input by the operator 
(the character that would occupy position 81) 

Is not a tab or carriage return, the terminal 
program will Insert another Input line 
(see FIELD EXPANSION), 

Instruction Entries 

26, Instructions are defined as data that will be 

processed by a program and then discarded. i 

Data element values, on the other hand, become 

part of the data base and are stored. An 
example of an Instruction would be Information 



telling the program to print out a set of catalog 
cards . 
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Instruction entries begin with a two-posltlon 
error code field. This Is followed by a single 
space. These first three positions are protected. 
The Input field for the Instruction follows. It 
Is fixed In length and Is not labeled. 



28 . 



Instruction fields are prompted with underscore characters 

This differentiates them from data element Input 

fields. 



29. Instructions should be 
codes, such as "M" for 



"I" for "Invoice received" or 
received with Invoice." 



In the form of short 
"material received" or 



"Ml" for "material 



30. The length of an Instruction input field Is 
determined by the length of the longest 
Instruction, or set of Instructions, that 
may occupy that field. 

31. Instruction entries must begin In position 1 

* * * DOCUMENT ENDS * * * 
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3.4 BALLOTS COMMAND LANGUAGE 

Thf» following Is a description of the BALLOTS command 

involved 8 1 n the BALLOTS-MARC module. (See also section 
2.4.7,) As other modules are added to the BALLOTS system, the 
command languag® wll* expand. BALLOTS comman s s ^ be 

conflict w?th other command languages with which users may 
familiar.' The tame function should have the same command word In 
all svs terns , and the same command word should call the same . 

f unctTon Tn a 1 1 ^ systems . The main 

the other existing command languages at Stanford Is that BALLUib 
deals with data one frame at a time rather than one line at a 

time. 



* * * DOCUMENT FOLLOWS * * * 
BALLOTS-MARC COMMANDS 



CANcel 
CONt 1 nue 
D I Splay 
ENTer 
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AND 
NOT 
OR 

BACkup 

format routine calls: 

BF01 
B I 01 
B I 02 
GS01 
HH01 
QR01 
SI01 
SI 02 
IGNore 
KEEP 
LOGON 
LOGOFF 
paging 
+ 

+ B 
-B 

REStore 
SCRatch 
SEArch ' 

SET 
SKIP 

Most commands may be Input using eltner cne nrst 
letters or the whole command. The only exceptions are LOGON and 
LOGOFF/ which cannot be abbreviated. All commands may be Input 
In upper or lower case. 

In the discussion of commands/ reference will be made to the 
following levels of activities. Each level may be considered a 
logical set made up entirely of one or more occurrences of a 
member or members of the next lower level. 

FUNCTION Ordering Function 

Catalog Function 
Scratch Function 

Search Protocol 

Standing Search 
Build Protocols Order 

Catalog 

Scratch Protocol 

FORMAT ROUTINE BF01 

B I 01 



PROTOCOL 



Search Results - Full Blbllograpn 

Input - Bibliographic 

Input - Additional Bibliographic 

General System Screen 

Input ~ Holdings 

Input ~ Ordering 

Search Input 

Search Continuation 
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B! 02 
GS01 
HH01 
OR 01 
St 01 
S I 02 



CYCLE 



Input Cycle 
Overflow Cycle 
Error Cycle 



Output Step (output of a 
frame by the system) 
Input Step (Input of a 
frame by the operator) 



Build protocols are those that write to the data base. They 
are called build protocols because they build a record In the 
data area of "user scratchpad memory" (USM). They are more 
strictly controlled than are protocols that only read from the 
data base. 



A format routine/ or simply a format, will 
a single cycle. If a format overflows a single 
overflow cycle will be initiated. If the edit 
error in Incoming data, an error cycle will be 



often consist 
frame, an 
program finds 
ini tlated. 



of 

an 



A cycle Is the period beginning after the operator has 
transmitted a frame and continuing until the operator transmits 
the next frame. 

CAN cel Command 



CANcel is one of the two commands that can end a build 
protocol. The other Is the ENTer command. It is Impossible for 
the operator to exit from a build protocol without using one of 
these commands. The effect of the CANcel command Is to clear the 
build area In USM. When the build area Is cleared by a CANcel 
command, the status of all data Is reset to what it was at the 
beginning of the build protocol: no files are updated, no print 
records are produced. 



CONtinue Command 

In BALLOTS-MARC the CONtinue command will be used to call 
for more Input positions In a BI02 format when these additional 
positions are not provided by automatic paging. This condition 
will occur when the following three factors are all present: (1) 
all data in USM that should be Included In a B102 format has 
already been displayed on previous frames of B 1 02 or Is being 
displayed on previous frames of BI02; (2) the last data element 




60 



56 



on the screen Is In line 24 but does not continue past position 
77; (3) the operator has more data elements to Input in the BI02 
format. The same Is true for the HH01 format. 

Display Command 

1 

The Display command will cause the records pointed to by the 
current results stack of the search area to be displayed In the 
BFOX format. The records will be displayed In CRD order. The 
display command does not end a search protocol , and it does not 
affect the results stacks or the build area In USM. 

ENTer Command 

ENTer Is one of the two commands that can end a build 
protocol. The other Is the CANcel command. It Is Impossible for 
the operator to exit from a build protocol without using one of 
these commands. The effect of the ENTer command is to take the 
record In the build area In USM and update files and/or produce 
print records as necessary. The successful execution of the 
ENTer command signifies the acceptance of the new record/ or 
update/ Into the system. Finally/ ENTer releases the build area. 



F I Nd Command 



The FINd command initiates a search protocol. It will begin 
by clearing the search area In USM. The actual search will be 
handled through the SPIRES/BALLOTS common software. The AND/ 

NOT/ OR/ and BACkup commands may occur within a FINd comma nc\ 

A search request Is composed of the command "FINd" fol 7ed 
by the name of at least one index and at least one value fo- hat 
Index. The Indexes available In BALLOTS-MARC wl 1 1 be p^rso al 
name (PN)/ corporate-conference name (GN)/ title word ( j) / ?r»d LC 
card number (CRD). If more than one Index-value pair Ir 
contained In a request/ each pair must be connected with one of 
the logical operators "AND/" "OR/" "NOT." A request containing 
only one pair Is called a simple request. A request containing 
more than one pair Is called a compound request. 



Examples: 

a. (simple) 

b. (simple) 

c. (compound) 

d. (compound) 



FIND TITLE HONOR 

FIND T GLORY 

FIND PN SMITH AND JONES 

FIND PN SMITH AND JONES AND T HONOR 



In example C/ the system would find all works written both by 
someoh$ named Smith and someone named Jones. In example d/ the 
system would find all the works that were written both by someone 
named Smith and someone named Jones and that had the word "Honor" 
In their titles. 
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The precedence of logical operators Is left to right/ with 
grouping capabilities provided by the use of parentheses. A new 
search Is started by specifying the command verb "FINd." 

Example: FIND PN HUNTER AND <T PRAY OR T REWARD) 

If several values are specified for one Index In a request, the 
name of the Index need not be repeated. 

Example: FIND T HAPPY OR GLEEFUL OR ECSTATIC 

If several title words are specified without logical operators 
connecting them, "AND 11 will be assumed and need not be specified. 

Example: FIND T TAMING OF THE SHREW 

The system responds to a FINd command with a count of the 
number of records that match the specified criteria. Such a 
response always appears In a SI 02 format. If the number of 
matching records Is exactly one, that matching record will 
automatically be displayed on a display screen (always BF01 In 
BALLOTS-MARC) and there will be no statement of the search 
results. If the number of matching records Is not exactly one, 
the number of records found In the search will be displayed on 
the SI 02 screen and the user can enter a request that will 
Increase or decrease the number of records found. 

The user may go through many search Iterations, entering 
successive requests to reduce or expand the set of records that 
meet his specifications. Occasionally, he may enter a request 
that reduces or expands the search result by much more than Is 
desirable at that point. Rather than have to re-enter the entire 
search specifications, the user may then use the BACkup command. 
This command allows the user to request that the search status be 
reset to what It was before the last request. If a user enters a 
request that reduces the set of records found to zero, the system 
automatically backs up to Its status before that request. 

Special conventions are Involved In specifying Index values 
for the personal name Index. Remember that the user may Input In 
upper or lower case without having any effect on the search. 

Format Routine Call Command 

The format routine call command consists of a format I.D. 
This command Is used to call up a certain format, subject to the 
rules of the protocol. In some cases this command will Inltate 
a protocol. This command can be used to jump ahead In a 
protocol, bypassing Intermediate screens. 
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IGNore Command 



The IGNore command Instructs the system to disregard all 
actions taken during the current cycle. The contents of USM will 
In no way be affected by the transmission of the current frame. 

The system will respond with the transmission of a frame 
Identical to the last frame transmitted. If that frame was 
blank/ the retransmitted frame will be blank/ regardless of how 
much data the operator may have Input before issuing the IGNore 
command. This equals a "clear variable data" function within the 
terminal. If the last frame contained data from USM/ the 
retransmitted frame will again contain that data unaltered. If 
the IGNore command Is linked to another command/ e.g./ IGN/ENT, 
the retransmission of the frame can be circumvented. 

KEEp Command 

The KEEp command Initiates a standing search build protocol. 
The effect of this command Is to take the current form of the 
FINd command from the search area / pass It through the standing 
search edit rules/ and display the edited search command for 
review by the user. The KEEp command builds a standing search 
record In the USM build area at the same time. The KEEp command 
does not affect the search area and the result stacks contained 
therein. 

Paging Commands (Display Only) 

The four paging commands are +/ +B/ -/ and -B. In the MARC 
system they are used only with the BF01 format. The + command Is 
used to advance to the next frame when a single record Is too 
long to be displayed In one frame. If a record Is only one frame 
long/ or If the last frame for that record Is currently being 
displayed/ the + command will be rendered Inoperable. The + 
command will not page ahead to a frame displaying another 
record; the +B command must be used for that. 

The +B command Is used to page ahead to the next bibliographic 
structure. That Is/ I t wl 1 1 page ahead to the first frame of the 
next record. It will jump over any remaining undlsplayed frames 
of the current record and go directly to the beginning of the 
next record. If there are no succeeding records/ the +B command 
will be rendered inoperable. 



The - command Is the opposite of the + command. It Is used to 
back up to the previous frame of a record that Is too long to be 
displayed In one frame. Obviously/ the operator must have first 
issued a + command In order to be In a position to enter a - 
command. If a record Is only one frame long/ or If the first 
frame of a multiframe record Is currently being displayed/ the - 



command will be rendered inoperable. The - command will not page 
back to a frame displaying another record; the -B command must be 
used for that. 

The -B command Is used to page back to the previous 
bibliographic structure. That Is, It will page back to the first 
frame of the previous record. It will jump over any previous 
frames for the current record/ and will also jump over any 
trailing frames for the previous record. if there are no 
previous records/ the — B command will be rendered inoperable. 

Automatic Paging 

Frame overflow In input and update format routines will cause 
automatic forward paging. In a prompted mnemonic format/ e.g. 
BI01/ the format routine has a list of all data elements con- 
tained In the format. If any of these elements has been pushed 
off of a frame/ the routine will automatically transmit another 
frame. This succeeding frame will repeat the last two lines of 
the preceding frame and follow these two lines with the rest 
of the data elements In the format. In operator-supplied mnemonic 
formats/ e.g. B102/ If there Is any data beyond position 77 of 
line 24/ the routine will automatically transmit another frame 
with a two-line overlap of the preceding frame. In the case 
of an operator-supplied mnemonic update format/ If there Is data 
in USM that has not yet been displayed/ thSs data will cause 
transmission of another frame regardless of the contents of line 
24. 



If the operator finishes a data element in line 24 before 
reaching posltton 78 and wishes to input additional data elements/ 
the CONtinue command must be used. 

REStore Command 

The REStore command re-initiates a format routine. If the 
REStore command Is Issued without a modifying format I.D. 
following It/ it Is assumed to refer to the format currently 
displayed. A REStore command always resets the format routine 
to the first frame. The REStore command Is executed after the 
current frame has been processed. (Compare with IGNore command.) 

If the REStore command is followed by a format I.D./ the 
current frame at the terminal will be processed and then the 
named format will be displayed with data from USM. This allows 
the operator to back up in a build protocol. The format I.D. 
must refer to a preceding format routine within the current 
protocol. If the format I.D. refers to a succeeding routine/ or 
to a routine in another protocol/ the REStore command will not 
execute. 
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The second form of the REStore command may perhaps not be 
Implemented as a part of the BALLOTS-MARC module. 



RES B I 01 



RES SI 02 



RES HH01 



RES OROl 



returns to the first frame of the BI01 format 
for the record being constructed In the 
build area. 

will return to the first frame of the BI02 
format for the record being constructed In the 
build area. 

returns to the first frame of the HH01 format 
for the record being constructed In the build 
area. 



will return to 
format for the 
the build area 



the first frame of the OROl 
record being constructed In 



SCRatch Command 

The SCRatch command Is used to delete a record. In the MARC 
system, the SCRatch command will be used to delete standing 
search requests. For this use, the command will have the 
the following form In the BDEN notation (see section 3.5): 

SCR(atchXSP(l)XSID> 

where <SID> is a standing search I .0. number. 

SEArch Command 

The SEArch command In the MARC module will Initiate a search 
protocol and prompt an SI01 format. In later modules this 
command may be used to specify which of several files are to be 
searched. In the MARC module, BMRC Is the default, one-and-only 
file. 

SET Command 

SET FUN(CTION)«<funct Ion name> 

SET LID»<1 Ibrary I .D. > 

SET 01 D=<operator I.D.> 

The SET function Is used to change the last three fields of 
the control line. The Initial value of these fields Is set during 
the LOGON procedure. 



SKIp command 

The SKIp command Is used to jump over succeeding frames of 
format to another format. If no format i.D. is specified, the 
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SKIp will be to the next format In the protocol. The SKIp 
command may be followed by a format routine call command to 
skip over succeeding frames and Intermediate formats In a 
single bound. (See linking of commands.) The SKIp command Is 
executed after the data In the current frame has been processed. 
The SKIp command In no way affects the contents of USM. 

When In BALLOTS-MARC the operator enters In build order or 
build catalog record protocol, USM will contain the full MARC 
record retrieved by the search. The use of SKIp to by-pass any 
part of B 1 01 or BI02 will not delete the portion of the MAR^ 
record that would have been prompted in the skipped part. 

Linking of Commands 

In some cases It Is possible to link commands together. This 
is particularly true at the end of a protocol where an ENTer or 
CANcel command may be linked to another command to Initiate a new 
protocol. Linking Is done by using a slash, /. 

CAN/DI S 

CAN/FIN <search argument> 

CAN/ LOGOFF 
CAN/SEA 
CAN/BF01 
CAN/GS01 
CAN/SI 02 
CAN/SI 01 

ENT/DI S 

ENT/FIN <search argument> 

ENT/LOGOFF 
ENT/SEA 
ENT/BF01 
ENT/GS01 
ENT/SI 01 
ENT/SI 02 

IGN/RES (format I.D.) 

SKI /ENT 
SKI /HH01 
SKI/OR01 



Procedure of Commands 

All commands except CANcel and IGNore are processed after the 
data in the current frame has been processed. If an error condition 
exists, the current frame will be redisplayed and the operator 
must then correct the errors. If the command was originally 
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prompted as part of the format. It will be reprompted when the 
frame Is redisplayed; otherwise, the operator must reissue the 
command. In the case of CANcel and IGNore, the command Is executed 
Immediately; the data In the current frame Is not processed and 
there are no error cycles. if a command Is Invalid, a diagnostic 
message will be displayed In the message line. 

* * * DOCUMENT ENDS * * * 



3.5 BALLOTS DATA ELEMENT NOTATION . 

BALLOTS development depends In part on the facility with 
which data element descriptions and processing rules cari be 
formulated and communicated. It was found both Inefficient and 
ambiguous to use conventional, prose descriptions for this 
purpose. Consequently, a method was developed that allows very 
precise, shorthand documentation of this Information. This 
method Is called BDEN--BALLOTS Data Element Notation. BDEN Is 
somewhat similar to BNF (Backus-Naur Form), a familiar 
metalanguage. A BNF analyzer was used to detect any ambiguities 
that might arise In data element descriptions written In BDEN. 
BDEN was developed to overcome three deficiencies In conventional 
BNF: (1) five to six different productions were required to 
specify and describe a data element, (2) video terminal screen 
column positions could not be specified for Input work; (3) It 
was difficult to show which components of a complex data element 
belonged together. BDEN enables a data element to be completely 
specified with a single production. In a single line. In 
addition to describing the data elements, BDEN Is also used to 
describe output formats and the location of data elements. The 
language has proved a useful means of ensuring accurate 
communication between the library analysts and the programming 
staff. Members of the library staff have also become proficient 
In Its use. The following detailed explanation of BDEN Is taken 
from BALLOTS Documentation Standard DS.124. 

* * * DOCUMENT FOLLOWS * * * 

The BDEN system of notation has been developed to provide a 
standardized short-hand method for the precise description of 
data elements. BDEN notation takes the form of productions that 
look similar to equations. There are two classes of productions, 
one that defines the Internal format of Individual data 
elements, and a second that describes the use of data elements 
In on-line displays and printed outputs. The first class always 
contains a data element mnemonic as the left side of the 
production. The second class always contains a display or print 
position as the left side of the production. 

ex: CLASS I 

(IDX): :=<NUM(1-6)XNUM(1)CD>.<NUM(2)> 



CLASS-4 I 
< 4 >3 > : : = CTUT) 

\ 

I. A group of special symbols, < > ( ) 1 : : I s used to Indicate 
the functions of various elements of BDEN descriptions. 

1. < > ANGLE BRACKETS 

Angle brackets around the left side of a production 
signify that the production Is describing data in display 
format. 

ex: < I DX> : : = 

<4, 1> : : = 

Angle brackets in the right side of a production enclose 
the description of required data that is variable in content. 

ex: : : =<ALPHA( 2 ) > 

: : -<TST> 

2. ( ) PARENTHESES 

Parentheses around the left side of a production 
signify that the production is describing data in input 
format. 

ex: ( I DX ) : : = 

(4, l):.:*" 



Parentheses within the left side of a production 
enclose information concerning the length of a field 
(see POSITION COORDINATES, 11.13 below). 

ex: <4, 1 ( 10)> : := 

Parentheses have two different uses in the right side 
of a production: 

a. <()> When the parentheses occur within the angle brackets, 
the parentheses enclose information concerning the 
length of a unit of data 
(see LENGTH, 11.6 below). 

ex: : : =<ALPHA(2 )> 



b. (<>) When the parentheses occur outside the angle brackets, 
the parentheses indicate that the data described within 
the parentheses is optional. 



/ 



ex: 



: : =(<NUM( 3 )> ) 

: : =<NUM(3 )> (-)<NUM(3 )> 



O 

ERIC 



3. 



4. 



5. 



I I . 



• * SINGLE QUOTES 

Single quotes around the left side of a production 
signify that the production Is describing data In print 
format. 

ex: ' I DX ' : : = 

'4,1'::= 

Single quotes In the right side of a production enclose 
one of the special symbol s, < > ( ) I 1 ::*# when 
these symbols represent literal data and therefore are 
not being used as special symbols within BDEN. 

ex: : : = ' ( 'SEPN: <SP(2)XSEPM> ' ) ' 

When single quotes are used as literals# they are written: 11 1 

::«* DOUBLE COLON EQUALS 

This notation separates the left and right sides of a 
BDEN production. 

ex: BAC: :»<ALPHA(3)>-<NUM(3)> 

| LOGICAL OR 

Logical or's ^round the left side of a production 
signify that the production is describing data in storage 
format. 



ex: | 1 DX | : := 

| 4# 1 1 : : 3 

The logical or on the right side of a production indicates 
exclusive alternatives in the form and content of data. 

ex: ::»<MEPN> 

| <MECA> 

| <MECF> 

| <MET> 

I <MEUT> 

: : a <ALPHA(3)>-<NUM(3)> 

| <ALPHA(3)X<SP(1)>)<NUM(3)> 



The various aspects of data elements are described according 
the following conventions. 
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1. ADDITIONAL CHARACTER SET 

(See CHARACTER SET , 11.2 below.) 

2. CHARACTER SET 



(See also ADDENDA, below.) 



The character set of the data being described may be Indicated 
by using on# of the following codes. 



ALPHA 

ALPHANUM 

BIN 

CHAR 

DEC 

HEX 

NUM 

SP 

SPEC 



letters A-Z 

letters A-Z and digits 0-9 

digits 0-1, to be read as binary numbers (base 2) 
letters A-Z, digits 0-9, and all special 
characters 

digits 0-9, to be read as decimal numbers 
(base 10) 

digits 0-9 and A-F, to be read as hexadecimal 
numbers (base 16) 
digits 0-9 
space 

all special characters I.e. all characters that 
are not letters or digits. This includes all 
punctuation and diacritical marks. 



It is possible to specify a combination of two character 
sets. The ADDITIONAL CHARACTER SET must be separated 
from the Initial CHARACTER SET by a comma. The only two 
codes that may be used for ADDITIONAL CHARACTER SET are 
"SP" and "SPEC." If, for example, a field could contain 
only alpha characters and spaces, it could be described as: 



ex: : :»<ALPHA,SP(4)> 



When character sets are linked together, they must be 
separated by commas. 

If none of the above codes is sufficient, an EXPLICIT 
CHARACTER SET can be Itsted. If, for example, a 
field could contatn either a "Y" for "YES" or an 
"N" for "no", and nothing else, the character set 
could be described: 

ex: : : =<YN (1)> 



The EXPLICIT CHARACTER SET must be separated from fcre 
destgnatton of LENGTH by a blank. If a field could 
contatn only alpha characters, periods, and commas. 



question marks, and parentheses. It could be described 
as : 

i 

ex: ::»<ALPHA, .;,?() (4)> 

In the above example, the first comma separates the 
CHARACTER SET code "ALPHA" from the EXPLICIT CHARACTER 
SET. There should be no comma between the Individual 
members of EXPLICIT CHARACTER SET. Also, there should 
be no comma between the EXPLICIT CHARACTER SET and 
LENGTH, but there must be a blank. If the EXPLICIT 
CHARACTER SET Is very large. It Is better to list It 
In a table than to describe It all within BDEN. 

The NAME convention can be used to facilitate this 
(see NAME, 11.11 and lll.l below). 

Any indication of character set Is always followed by 
LENGTH, enclosed In parentheses 
(see LENGTH, 11.6 below). 

3. COLUMN NUMBER 

(See POSITION COORDINATES, 11.13 below. 3 



4. EXPLICIT CHARACTER SET 

(See CHARACTER SET, 11.2 above.) 



5. 



6 _. 



FORMAT 



BDEN allows for the definition of four formats 

for a data element. These are input for»at, storage format, 

display format, and print format. The 

format being described by any BDEN production Is 

Indicated by the special symbols around the left side of 

the production. 



ex: (XXX): :=» 

1 XXX I : : = 
<XXX> $ : a 



describes 

describes 

describes 



an input format 
a storage format 
a d I s plisay f o rma t 



*XXX* : : 3 

LENGTH (OF DATA) 



describes a print form at 



The length of a certain unit of data is Indicated 
by placing a number In parentheses after the 
Indication of the CHARACTER SET. The number of 
characters mt£St always be preceded by act Indication 
of CHARACTER SET. The number may be a rise:? "ength 
or a range.. 
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ex 



• • 



<ALPHA( 3 ) > 
<ALPHAC1-5G)> 



Use (n) to Indicate .an undefined range* 



ex : : :=<NUM(n)> 

: : =<NUM( 3-n ) > 



If the range or number of characters is not 
but will be known at the time a processing 
because of previous processing/ use a star 
the number. 



presently known, 
rule Is executed 
to indicate 



ex: : :=<NUM(l-*)> 



Zero is not a valid content for LENGTH. 
If a unit is optional, use parentheses 
indicate that fact (see l.2.b above), 
do not use commas to separate hundreds 



to 

When writing numbers, 
from thousands. 



ex: 1000 (not 1,000) 



7. LENGTH (OF FIELD) 

(See POSITION COORDINATES, 11.13 below.) 



8. LINE NUMBER 

(See POSITION COORDINATES, 11.13 below.) 

9. LITERAL VALUES 

A literal value is data that is fixed tn content and 
in form. A literal value Is noted without any conventional 
symbols surrounding It unless one of the conventional symbols 
Is a part of the literal value. In the latter case, enclose the 
conventional symbols with single quotes. 

ex : : : a D0G 

::='(' CAT ') ' 



When single quotes are used as literals, they are wrltteai: 



i i i 



10. MNEMONICS 



When a mnemonic is to represent the value of the data drhsit 
the mnemonic names, enclose the mnemonic with angle brevets. 

ex: : : =< I DX> 



To describe the literal value of a mnemonic, treat It as 
a literal (see LITERAL VALUES, 11.9 above). 

ex: ::=*IDX:<SP(2)XIDX> 



11. NAME 



Any unit of data enclosed by angle brackets on the right 
side of a CLASS I production (see BDEN PRODUCTIONS, 

1 1 1.1 below) can be named for ease of reference 
and Identification. Use some simple abbreviation 
and place It after the designation of LENGTH, A 
name may not contain blanks. 

ex: : :**<NUM(1)CD> 

Explanations of the functions of various named units and the 
Interrelation of these units may be given In notes and 
processing rules. 

12. NUMBER OF CHARACTERS 

(See LENGTH, 11.6 above.) 

13. POSITION COORDINATES 

(See also ADDENDA, below.) 

Posttton coordinates describe fields on screens, print 
formats/ and other I/O documents. Position coordinates 
do not describe the structure. Interior format, or length 
of data elements that occupy the fields In these I/O 
formats. (Compare this paragraph with LENGTH, 11.6 above.) 
Posttton coordinates are described on the left side 
of a Class II production (see BDEN productions, 

! I . 2 below). A position coordinate may have 
four elements: (1) line number? (2) column 
number; (3) field length; (4) signal to right- 
just tfy data In the field. 

model: LINE, CQUUMNCFTiE.LD LENGTH)5 IGNAL 

ex: 1 4, 3TZL0)RJ' r : 

Line number ts usually Indicated by some Integer. If 
only a relative posit ton Is {known, the symbol "L" may be 
used to represent current 1 line number. The statement 
"Start In column four erf the; next line" Is written: 
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ex 



L+l,fc 



14. 

i 

l 




Relative columns may be treated in the same manner, using 
»C" to represent current column number. The indication of 
column is always separated by a comma from the indication 
of line. An Indication of line and column, which defines 
the beginning of a field. Is the minimum al lowabl e content 
for a position coordinate. To this may be added the 
length of field. Field length cannot be expressed unless 
line and column are specified. Field length is always 
enclosed in parentheses, and is always one fixed number, 
not a range. When field length Is specified, it can be 
followed by the code "RJ," which means right justify 
data in this field. Otherwise, left justification 
is assumed. 



SPACE 



A space is described <SP(1)>. 

Three spaces would be described <SP(3)>. 



BDEN PRODUCTIONS 



There are two classes of BDEN productions. 



CLASS I deals with the internal structure of 
It describes the various units of Information 
by specifying the character set and number of 
of data, and by indicating whether a unit is 
optional part of the data element. 



a data element value. 

In a data element value 
characters In each unit 
a required or an 



CLASS I model: 



Data element mnemonic: := , , ^ . 

<char set, add char set, explicit char set (length) name) 

The data element mnemonic on the left side of the production 
will always be enclosed by one of the sets of special symbols 
to Indicate which format the production is defining (see 
FORMAT, 11.5 above). On the right side of the production the 
angle brackets enclose a required unit of data of variable 
content. A unit must: contain at least one specification of 
CHARACTER SET and a specification of LENGTH. There may be any 
number of these units In a data element description. Units of 
literal data are placed in their proper position between 
the variable units, “he literal units are not enclosed In 
angle brackets. A name ts not required for the variable data. 
Literal data cannot be named. 

CLASS I example: 

( I DX ) : : =<NUM< 1-7) ><NUM( 1)CD> . <NUM( 2 )> 




This description means that the input format for data element 
IDX consists of four units, all of which must be present. 

The first element Is composed of one to seven digits. The second 
Is one digit, named CD. The third element Is a period. The 
fourth element Is composed of two digits. The purpose In 
naming the second unit CD Is to facilitate reference to that 
unit In processing rules. For IDX there must be a processing 
rule that explains that unit CD Is a mod 11 check digit on all 
the numbers that precede it. If there are several alternate 
formats that are acceptable, they may be shown by using the 
logical or. 



(BAC): :»<ALPHA(3)>-<NUM(3)> 

I <ALPHA(3)>(<SP(1)>)<NUM(3)> 



2. CLASS II deals with the use of data elements In I/O formats. 

It describes various fields In an I/O format by specifying the 
position of the beginning of the field in the format and Indicating 
the data to be associated with that field. 

CLASS I I model : 



post tfon: : a data description 

Position Is defined by using POSITION COORDINATES (11.13 above). 
These coordinates will always be enclosed by one of the sets of 
special symbols. These symbols Indicate she format type of the 
data described on the right iide of the production (see FORMAT, 
11.5 above). This Indication of format applies only to the form 
of the data element. It does not apply to the form of the I/O 
document being described. If data element IDX were for some 
reason to be displayed In Its Input format on an output screen, 
the production would be written: 



(4, 13) : :»< I DX> 

not 

<4,13>:;: a <IDX> 



The angle brackets around the mnemonic In the above example 
signify that the field cannot be blank. 

If the data Is optional, the mnemonic will be enclosed by 
parentheses. 



ex: (12,1): :=(RSAD) 



If a field must contain some special characters In addition to 
the value of the data element, these characters are described as 
1 1 teral data. 



<3, 4> : : » 
<19, 1> : : 



PR0:<SP(2)>< PRO> 
*' ( ' SEPN ' ) ' 




^5 



ex : 



In many cases, however, such special symbols may already be 
a part of the data element format. 

If a field may contain any one of a group of data elements 
depending on which one Is present In the record, the alternatives 
are listed using the logical or. 

ex: <9, 1>: :=<MEPN> 

I <MECA> 

I <MECF> 

I <MEUT> 

I <MET> 

ADDENDA 

11.2 CHARACTER SET 

For use In describing control characters on the Sanders terminal, 
add the following symbols to the list of character sets: 

C/R = carriage return character 
H/M = home character 
H/T * horizontal tab character 
V/T * rtlcal tab character 

A single horizontal tab would be described as: 

<H/T(1)> 

11.13 POSITION COORDINATES 

Screen coordinates must indicate the BLOCK, as well as the LINE 
and COLUMN number. BiJ&K Is Indicated by a single alpha placed before 
the LINE number and s ega a r ated from that number by a comma. 



(A, 1, 1 ) 



This notation describes; the upper-left-most character position on the 
screen and Indicates tin's!: this position ts in block A. Line and 
column are read to mean absolute screen posttion, not relative 
block or buffer postticon^ A location at line 6, column 3, In block 
C would be described: 

(C,6, 3 ) 

even through this might be the ftrst posttion In block C. 

* * * DOCUMENT ENDS * * * 
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3.6 PROGRAMMING LANGUAGE CHOSEN FOR BALLOTS II 

Portions of BALLOTS I were coded In PL/1 and portions 
were coded In Assembly language for the 360/67 computer. It was 
felt that there were serious drawbacks to each of these languages 
and an Investigation of available languages was conducted. PL/1 
had the advantage of generating code quickly, but unfortunately 
the core requirements and execution time for the code were a sub- 
stantial disadvantage. Assembly language, on the other hand, 
allowed efficient utilization of core and machine cycles but 
took an extended length of time to program. After an extensive 
survey of available assemblers and compilers, PL360 was chosen. 
PL360 Is an algol-llke language that Is still close enough to 
assembly language coding to allow the user to control the use 
of computer registers. The PL360 language has essentially 
all the power of assembly language and yet allows the programmer 
to concentrate on the essential programming tasks. The 
following SPIRES document gives the "Coding and Description 
Standards for the Use of PL36Q." 

* * * DOCUMENT FOLLOWS * * * 



1. introduction 

This Is a description of the placement of code and comments on the 
page Itsttng; the nature of auxiliary descriptive text; preferred 
language constructs for efficient, compact object code; and 
control of source code versions. 

2. Hierarchy of Indentation 

PL360 Is a block-structured, procedure-oriented language: 
logically related sequences of statements may be grouped and 
nested by means of the delimiters BEGIN and END. The COMMENT 
symbol allows descriptive remarks to be Inserted anywhere within 
the code (except in literals) where a blank may be placed; 
the COMMENT symbol and following characters through the next 
semicolon are Ignored by the compiler. 

Although PL360 Is free-fleld, this property should be exploited to 
deftne a seml-flxed format that helps the eye, with Its pattern 
recognition ability, to grasp the organization of the program. 

(The same goal Is further advanced by using FOR, CASE, and 
WHILE statements wherever possible to replace the IF-GOTO 
combination. ) 

The basis for the format Is the INDENTATION LEVEL. For con- 
creteness, the left-hand margin Is taken as level 0, and each 




73 



77 



higher level Is five columns to the right of the previous level. 

A CONTINUATION COLUMN Is two columns to the right of the current 
indentation level. Since literals must be continued from the 
left-hand margin they should. If possible, be kept short enough 
to fit on one line by splitting them or by starting a new line 
before beginning them. 

In the following paragraphs, DUMMY BASE can be substituted for 
BEGIN, and CLOSE BASE can be substituted for END. 

BEGIN and END are always the first symbol in any line in which 
they appear (exception: labels, discussed below). BEGIN signals 
the last line of the I th Indentation level with succeeding lines 
to be governed by the (l+l)st level. Only BEGIN can Increment 
the current Indentation level. END signals the first line of the 
Ith Indentation level following zero or more lines at the (!+l)st 
level. Only END can decrement the current indentation level. 
Thus, matching BEGIN-END pairs can be Immediately Identified. In 
general, at most one complete statement or declaration appears 
on a line; however, several short, logically related statements 
may appear on a single line. If It Is necessary to continue a 
statement on following lines, then they start In the continuation 
column of the current level; this rate Is superseded by the 
begln-end criterion. Thus: 

FOR R2:=R1 STEP 4 UNTIL R3 DO 
COST ( R2 ) : “QUANT ( R 2 ) *PR I CE ( R2 ) ; 

COMMENT: CALCULATE CHARGES FOR M CUSTOMERS; 

but FOR R2s=Rl STEP 4 UNTIL R3 DO 

BEGIN R6: a X2(R2)+X3(R2); 

R6:«R6 SHLA 2; 

END; COMMENT: NOW R6 CONTAINS THE X FIELDS IN 
PACKED FORMAT; 

similarly, CASE R4 OF 

BEGIN COMMENT: PERFORM OPERATION 1, 2, OR 3; 
BEGIN COMMENT: OPERATION 1; 

<stmt>; <stmt>; <comment>; 

<stmt>; <comment>; 

<stmt>; <stmt>; <comment>; 

END; 

<stmt>; COMMENT: OPERATION 2; 

BEGIN COMMENT: OPERATION 3; 

<stmt>; <stmt>; <comment>; 

<stmt>; <stmt>; <stmt>; <comment>; 

END; 

END; 

A semicolon Is not required after BEGIN. END should be 
followed by a semicolon except when It Is Immediately 
followed by ELSE. 
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Internal procedure declarations are governed by the current 
Indentation level. Labels/ which must be easily locatable In the 
code/ are handled as follows: regardless of the current 
Indentation level/ a label definition always starts at the 
left-hand margin. For example 

THERE: <stmt>; <comment>; 

<stmt>; <comment>; 

BEGIN <decl>; <comment>; 

HERE: <comment>; 

<stmt>; <comment>; 

BEGIN <stmt>; <comment>; 

IF » THEN GOTO HERE; 

<stmt>; <comment>; 

END; GOTO DONE; 

NEXT: <stmt>; <comment>; 

<stmt>; <stmt>; <comment>; 

DONE: 

END; <comment>; 

END; 

A long label definition may overlap Into the current Indentation 
level/ forcing the beginning of the statement to the right. The 
colon should be followed by at least one blank. If a BEGIN or 
END would be forced out of position by a label definition/ then 
the definition Is placed on a line by Itself prior to the BEGIN 
or END. 

3. Comments 

Comments embedded In the source listing are one of the most 
Important parts of program documentation for debugging/ system 
Integration/ and maintenance. A we 1 1 -documented program may be as 
much as 40 to 50 percent comments. 

Comments have several functions. A comment may: describe the 
purpose and general structure of a procedure; Identify the use to 
which a particular declaration will be put; describe the 
(supposed) state of the program (variable values/ register 
contents) at a certain line of code; specify the Intent of one or 
several lines of code; convert an executable statement used for 
debugging Into a self-history; or justify a design decision about 
a construct or algorithm used/ and why alternative choices were 
rejected. 

The position of a comment In the listing gives a clue to Its 
scope. A comment centered on the page or consisting of asterisks 
across an entire line separates segments/ global procedures/ or 
major sections of code. A comment starting at the current 
Indentation level or Immediately after BEGIN applies to code 
following It. One starting after a statement on the same line/ 
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or In the continuation column of the following line, applies to 
that statement or to the state of the program after that state- 
ment. A comment Immediately following THEN or DO describes the 
consequences of the satisfaction of the condition prior to the 
THEN or DO; a comment after ELSE describes the consequences of 
the failure of the condition: 

IF -•= THEN COMMENT: SEARCH FOR ANOTHER MATCH; 
BEGIN COMMENT: INCREMENT I AND J; 

<stmt>; <comment>; 

<stmt>; <comment>; 

END ELSE COMMENT: STORE ADDRESS OF MATCH; 

BEGIN <stmt>; <comment>; 

<stmt>; <comment>; 

END; COMMENT: SEARCH DONE. @T IS IN ALPHA; 

4. Declarations 

Declarations are systematically ordered and grouped within a 
global procedure to lessen the possibility of error and to make 
them easy to locate. The order should be as follows: 

1. Register name synonym declarations, ordered either 
alphabetically or by register number. 

2. External procedure declarations, ordered alphabetically. 

3. Dummy base declarations. 

4. Function declarations. 

5. Long real cell declarations. 

6. Real cell declarations. 

7. Logical cell declarations. 

8. Integer cell declarations. 

9. Short Integer cell declarations. 

10. Byte and character cell declarations. 

Cell declarations that overlap each other, or must be grouped In 
adjacent locations? may be ordered differently, but this fact 
must be made clear through comments. 

Programs with large numbers of register and cell Identifiers make 
use of the following naming convention: the first letter of each 
Identifier names the type, and the remainder is arbitrary, 
generally a meaningful mnemonic. Exceptions are predeclared and 
external Interface Identif ler? *\ych as dummy base variables, 
and functions or procedures, 

F long and short floating-point registers. 

R general-purpose registers. 

E real cells. 

D long real cel Is. 

L logical cells. 

B,C byte or character eel Is. 



76 

80 



H short Integer cells. 

I,J,K,M,N Integer cells. 

5. Efficient Constructs 

! 

To clear a register: I 

FO : “FO-FO; 

F01 : *F01-F01; j 
R6:»R6-R6; f 

R6:»ZER0; (When ZERO Is RO and contains 0.) 

! | 

I i 

Use the following functions: 

FUNCTION REDUCE(6,#0600), 
SETUP<6,#0500), 

BRANCHC 15, #4 7F0), 

ADDRC 2/ #4100)/ 

SETZONE(8,#96FO); 

REDUCE Is a BCTR Rx/0 Instruction. For example, 
REDUCE(Rl) Is preferred over R1:=R1-1; 

SETUP Is a BALR Rx,0 Instruction. Thus SETUP(Rl) 
sets R1 to the address of the halfword following the 
current Instruction, usually another Instruction. 

BRANCH Is a BC 15, <! ndexable address> instruction. 
BRANCH(B2(Rl+4) ) causes a jump to the location given 
by R1+R2+4. Usually SETUP Is used to establish one 
of the registers and the other Is an Index. 

ADDR Is an LA Rx, «*<1 1 teral value> Instruction. For 
example, ADDR(R1, "-Hi THERE SAM.") sets R1 to the 
address of the character string "-HI THERE SAM." 

SETZONE Is an 01 Instruction that OR's In a hexadecimal 
F in the zone portion of the addressed byte, e.g., 
SETZONE(B2(3)). 

Specify an n-way branch on R2, where R2 may contain 
0 through n-1: 

R2:-R2 SHLL 2; 

SETUP(Rl); 

BRANCHC Bl(R2+4 ) ); 

COMMENT: BRANCH CHOICES START HERE; 
»T0 A; COMMENT: R2»0; 

GOTO B; COMMENT: R2»l; 

GOTO C; COMMENT: R2»2; 

GOTO X; COMMENT: R2:=N-1; 

COMMENT: END OF BRANCH CHOICES; 
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Set R1 to the address of an error message specified by 
R2, which has a value 0 through n: 

IF R2>N OR R2<0 THEN R2:=ZER0; 

COMMENT: NEXT N+3 LINES MUST NOT BE MOVED; 

R2 : =R2 SHLL 2; SETUP(Rl); 

EXCRO/ B1 (R2+8 > ); GOTO Stj 

ADOR(Rl / "MESSAGE 0"); COMMENT: R2=0; 

ADDR( Rl/ "MESSAGE 1")5 COMMENT: R2<L; 

ADDR(R1 / "MESSAGE N"); CO WE NT : RS2*N; 

X: COMMENT: R1 CONTAINS JBTCAESS OF SELECTED P£SS 

Convert value of R1 to decimal/ limited to» k ^glts,, and put It 
at the address specified by R2: 

COMMENT: WORKAREA MUS" fB£ 8 BYTES ON 
BOUNDARY; 

CVD(R1/ WORKAREA); UNPHC1, 7, 32 , WORKAREA } 
SETZONE( B2( 3 ) ); 

Move memory FORWARD with possible overlap, w were Rx Is the 
number of bytes to move, Ry Is the source attrdress, and Rz 
Is the destination address: 

WHILE Rx>0 DO 
BEGIN REDUCE(Rx); 

I C(Ra, By (Rx)); 

STC(Ra, Bz(Rx)); 

END; 

COMMENT: Ra IS AN I NT1WMED I ARY FOR THE SITES,, 
Some short programming tips: 

Use Rx:=Rx++Rx tnstead of Rx:=Rx SHLL 1. 

Use Rx: »@Bx (constant ) Instead of Rx:»Rx+cwsrtant whenever 
the constant Is In the range 0 through 409B. 

Use Rx:»@Bx(Ry+constant) Instead of Rx:=Rx*Ry+constant, provider 
the constant Is In the range 0-4095. 

Use Rx: a NEG constant Instead of Rx:=-constarrt. 

To blank up to 256 bytes use 

MVIC" ",cell); MVC(n/cel l (D^celTl; 

where n Is 2 less than the total number of bytes tr» be blanked. 

Caution: MVC/ CLC/ UNPK # PACK/ ED/ TR/ TRT ff DC/ NC, and other 
Instructions that have length fields require the length to be 
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1 less than the actual length desired. Thus MVCtQ,B,A3 moves 1 
byte from A to B. 

6. Source Code Control 

This section discusses the separate listing to be- aaimtained -or 
each global procedure, and the rules governing mo!?: ! frlcatlon of 
these listings. 

? : he SHELL consists of the minimum declarat Ions, de {rafters, and 
code necessary to form a dummy module that can fens; ccsmpU ed and 
Vrnk-edited Into the system but that performs no ifuactlcn except 
so return. Once the shell has been approved the"® should be nc 
nseed to make any changes to It, except In the ewsrac. of changes In 
the design of system Interfaces, Including reglsc=er von 'ent Ions., 
Hraneter passing, etc. The shell Is fully comnaemte ! s d becomes 
r*art of the module documentation. 

The PRODUCTION VERSION Is the current approved naodi -fe actually In 
use In the system. Very rigid controls must be exercised over 
the modification of this source code. It contains r <mmient-form 
debugging statements from the test and Integration p a&'ts. If asm 
approved changes have been made since the last csoratplsne rewrite, 
the old versions of affected statements are present: Irr comment 
form. 

The TEST VERSION Is the programmer's working vers Hem,. rnlch he Is 
free to experiment with and modify at will. Most frequently It 
will differ from the production version only with respect to 
trial bug corrections or other Improvements. 

7. Auxiliary Descriptive Text 

Each module has prtnted maintenance Information fmtendied as an 
extension of comments In the source Itsttng. This AUXILIARY 
DESCRIPTIVE TEXT Is not Intended as a design speciflicatilon or 
functional specification. Where necessary, references to these 
other documents can be made. Material appropriate to this 
document tncludes, but ts not limited to: overall philosophy and 
layout of the program; mathematical analysis relation: to the 
specific algorithms; running-time analysts, both expseted and 
worst-case; and core usage. Frequent references to code line 
numbers IN THE PRODUCTION VERSION should be made where 
appropriate. 

PL360 is supported on the Campus Facility computer 
and has been documented by SHARE, the IBM User Organization. 

St nee the PL360 language was chosen for use on the BALLOTS 
Project, the compiler has been modifted to run In an Interactive 
mode allowing the programming staff to code ar»d execute 
program at orae sitting. 
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3.7 NETWORK FEASIBILITY STUDY 

Th» results of a preliminary cost study for the BALLOTS 
system (see section 3.8) showed that a very high p ercentage of 
t vie operating cost of the BALLOTS system would be In the overhea^ 
area; that is, the area required for operational continuity of ^tr^ 
system \updfetlhg of files, storage of f I les, etc. ), Independent 
of the amount of usage of the system. An additional study was 
nade to detsnrane what the costs would be if the amount or 
BALLOTS transact lions was doubled (i.e., an increase of 100 
percent of alii the file searching, printing of catalog card S' 
etc.). This study showed that the operational cost for doubling: 
the transact ism load would Increase the operating cost by 
approximately only 59 percent. It therefore seemed feasible tu, 
encourage other libraries to use the system and take advantage oof 
the I ncremgrrra 1 cost of the additional work load. 

It w£S 5 decided to investigate the possibility of a library 
automation -netEwork for local Bay area colleges and universities-. 
Four local coPTeges and universities participated in a 13-week 
workshop to dEttermlne the benefits, costs. Impact, advantages, 
and disadvantages, of using BALLOTS In their libraries. The 
workshop was from April Into July, 1971. The results of thl 
workshop were presented In a two-volume, 250-page report t a 
went to the library directors. The report was considered 
confidential. In that It contained Individual library costs, so 
this report was not generally distributed. A summary report t at 
included details of the cost methodology and some of the results 
of the workshop was written In a forms that could be dlstrlbuteffl- 
Thls summary report Is contained In Appendix D. Following is me 
text of a paper delivered at the 1971 conference of the American 
Society of Information Sciences. It contains a brief summary of 
the activities covered In the workshop. 

* * * DOCUMENT FOLLOWS * * * 

AN ON-LINE NETWORK--COOPERAT I VE PLANNING WITH SEVERAL LIBRARIES 

A- H. Epstein, Douglas Ferguson, and Eleanor Montague 

Stanford University 
Stanford, California 

Abstract 

A cooperative feasibility workshop. Involving five colleges 
and universities, was conducted at Stanford University over a 
period of 12 weeks. Its purpose was to determine 



the costs and 



ERIC 

vMMMrrilM 



benefits involved Id the use by a network :or a 11 b r&r Jj^tomat tors 
and Information retrieval system basing developed at i'^ord. 

After am orientation that promoted .open and continuing 
communication the participants wor^d t^ether to pmeau^e the 
tools and technique's for a feasibility analysis. This* a ^ a ^y s ' s 
established the network operating environment, the t*m*ac , of 
participation and system benefits ^ user libraries, *»£ the 
operational costs. Including compu ting, manual , and 4 vs P^ a £®<] 
costs. The results of the works her: were presented in form of 
a feasibility report to the 1 ^ror /• admin 5 strat Ion . 

Institution to aid israirogern^nt deci s Ion. jii&kJ og • The inc- totQx ds 
the study team developed, the work assignments, some Kirro-rma 
findings, and observations on the workshop are presences here. 

Introduction 

Stanford University is developing a large, on-i iirse. 
Interactive library automation CBAUL0T3)* and Information 
retrieval system (SPIKES)** to operate In a production 
environment. CRT terminals will be used for 1 1 br . sr ^ ,5?T'lI n ® sed 
Input and display, and typewriter or CRT terminals w .11 
for Information retrieval. Three main types of on-1 In* J 1 les are 
being designed for library use: (a) MARC-- Machine Readable 
Catalog— bibl lographlc data from the Library of Congress? (b) 
IPP-_ln process FI Te**records of the status of each We*oK 
ordered by the library but still In the processing cycle (not 
available for patrons' use!.; (c) Catalog and Circulation 
f I les— records of the location and status of each book in the 

col 1 ect Ion. 

The system Is being implemented In a series of modules. Each 
module permits additional types of book material to A* processed 
or adds new on-line files. The first module being rnaplemented _ 
(BALLOTS-MARC) Includes an on-line MARC file of the most recent t> 
to 12 months of MARC data for use In the technical processing of 
all books covered by the MARC data. The printed output of this 
module Includes purchase orders and catalog card sets ready for 
filing. 

The system is designed so that TSr can be extended to 
specialized libraries at Stanford^ such as the law’ library, as 



* Bibliographic Automation of Large Library Operations using a 
T Ime-Sha r 1 ng Systwr Cl ) . BALLOTS was part I a 1 1 y funded by 
grants OEG-l-071Jfe5-4428 and OEG-0-70-2262 from the U.S* Office 
of Education. 

** Stanford Public Information Retrieval System (1), SPIRES l« 
funded by a grant from the National Science Fosindat 
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well ss tc * rational net crk of libraries. From the point of 
view of a oocentlai user library, joining the network has f e th 

?illo-tng advantages °ve- Individual automation: a rostof^the 

developmenit and Instal latUon cost and time are large 

the operattlorral cost Is reduced by tin* 6 s ^ ar , ? . , n havp run 

computer; !cJ stable software and hardware, which *11 - 

under heawy production coradfltlons at Stanford for tour s 

“*5 ^«r5 r S S t^^n?bra?n^ 

i A 0 ii a f? f rf^i rssssrjrsE. 

££m£s usn??i^r.^u d ^ c, "‘ 

Inter! Ibrary loans. 

Thf* fa~«g-s I fr I 1 1 ty Study 

BALL^S a re re f ^na?’ l.bSS 

seve^I ^ear^^onege^and^ un Werstties^^meet'lngsln July 197® 
and February 2371. 

The participants In these meetings explored the P 0 ®***® 1 ® 
(15^1211 ness of 1 BALLOTS to other libraries. They agreed that a 

preliminary feasibility study was a PAf^he^Ib^uary^e^ST 11 
Ja-ielon to participate Ieb BALLOTS. Ac che February meeting# 

four schools agreed to cowrit the necessary personnel and time to 
this study Two senior librarians with technical processing 
SilrtaS werr«*ected by each school They met together wttn 
members of the BALLOTS staff at Stanford one da ^ ® 
weeks from April to July. The equivalent- of a J®^ nd d ^ r f ach 
week was spent by team members ait their * schools gather 

data for a cost analysis. 



straady Oolectl^es 

jr To understand how BALLOTS 
specifically* tfoe ALLOTS -MARC system 
sunoft 1 5 brary tEchrol ca 1 



will 



2L. To develop and test cooperatively 
a cost ^measurement wet bodo logy applicable 
within the time limits of the stsmy. This 
iwsithodplogy had to be un I form! y I cable 

without placing a heavy data-gat^ering burden 
on the staff of each library. I' 4 had to 
permit comparison off the costs or esicl sting 
manual procedures and the costs stvolved tin 
the use of BALLOTS-MARC. The stsurdardt zed 
raetliDdology hae too permit comparison between 
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libraries of tfie costs and times taken to 
produce a given unit or to perform a like 
activity. 

3 . To determine ways In which BALLOTS-MARC 
could be made of greater use to libraries out- 
side tff Stanford. 

4. To prepare a report that would provide 
cost end benefit Information for the Director 
of each library. This report would enable 
each library to determine the main Implications 
anr? results of Its participation In a BALLOTS 
regional network and would be sufficient for 
management to make a decision on whether 

or not to participate In a BALLOTS Network. 

Study Methodology. 



The stedy team met as a group at Stanford for six hours every 
Friday for 23 weeks. At the first meeting, team members 
described their backgrounds and Interests, the features of 
BALLOTS were reviewed, and each library was generally described 
by someone from that library. During subsequent sessions a cost 
measurement methodology was developed and applied. Each session 
ended with the assignment of tasks to be completed by the 
following session. At the next session, task results were 
reported and problems were discussed. Throughout, the emphasis 
was on creating a common framework for analyzing costs. 

Tfte feasibility study was root begun with a predetermined 
method ^or doling the cost analysis. A review of the literature 
on the subject Indicated tsrfia't a variety of methods has been 
developed under widely varying circumstances of library size, 
study objectives, validity requirements, and documentation to be 
produced. It was the purpose cof this study to achieve some 
fairly specific objectives fm a period of 13 weeks. An equally 
Important intention was to encourage the study team to Involve 
Itself fully la defining the study method and to benefit from the 
critical comments and experience of all team members. The 
result t ng costing methodology was the product of a Joint effort 
by the entire feasibility study team. 

Manual Coats 

For manual costs, the approach taken was C a) to divide 
sachnlcal processing Into 12 major functions; (b) to Identify the 
component activities of each function for which costs could be 
calculated; (c) to design and test forms for collecting and 
calculating manual costs; and Cd) to gather time and cost data. 



Both total function cost and unit output cost were calculated for 
each major function. 

A function was defined as a series of actions that produce an 
Identifiable and measurable result (e.g., a purchase order or a 
cataloged book). The Individual output of a function Is the Item 
to which a unit cost of production can be assigned. The 12 
functions Identified were: Ordering, Purchase Order Receipt, 

Norn- Purchase-Order Receipt, Distribution (of material with- 
in technical processing). Obtaining and Maintaining Library of 
Congress (LC) Data, LC Cataloging, Original Cataloging, Card 
Production, End Processing, Claiming, Cancellation, and Added 
Copies and Volumes. 

The component actions of a function are called activities. 
Activities are not always easily distinguished, and In different 
libraries functions that produce the same output may consist of 
different activities. 

After the functions were Identified, they were flowcharted In 
a team session In order to divide each function Into Its 
component activities. These charts were very simple block 
diagrams that labeled and sequenced the activities in a function. 
They reflected the slight differences In processing flow that 
existed arraopg the participating libraries. 



The majVor cost of an activity was Identified as the cost of 
the people performing the activity. Personnel times for 
activities were collected for three categories of personnel: 
professional assistant, and student. For each category of 
personnel at each library, an adjusted hourly wage rate was 
calculated based on productive hours (accounting for vacation, 
sldkness, and breaks) and Including average benefits for that 
library. As such, the adjusted rate Is higher than the standard 
hourly rate. Supervisory costs were Included In personnel costs 
only If the supervisor actually contributed time to the 
performance of the activity. 

Costs for equipment (e.g. xerox toner) and supplies (e.g. 
card stock) 'were added to the personnel costs for each activity 
to yield total function costs. Costs for overhead, space, and 
general office supplies were not Included. The purchase price 
and maintenance of equipment were not included. The unit cost 
for each function was obtained by dividing the total function 
cost by the number of outputs produced from that function. 

The study team did not attempt In Its methodology to balance 
total function costs within a department against departmental 
budgeted dollars. This could be done as a follow-up study and 
would have to take Into account pockets of activity not accounted 
for In this study. 



Manual -Au tomated Costs 



There are four kinds of costs Involved In the use of the 
BALLOTS network system. They are essentially costs "! e 

user will receive a bill each month from equipment manufacturers/ 
from the telephone company/ and from the Stanford Computation 
Center. The four costs are: on-line transaction costs for 
activities such as searching *or or modifying a record; batch 
transaction costs for printing purchase orders/ catalog cards, 
tc.; dedicated equipment costs for terminal rental and modem and 
elephone line charges; and overhead costs for file storage and 



e 

telephon_ _ 

updating and l*ne connection charges. 



To calculate a library's annual expenditure/ It was necessary 
to know the library's volume of transactions against the system. 

To secure this data / a statistics questional re was Prepared 
asked for specific figures on the amounts of data that would be 
processed through the BALLOTS-MARC system and on the number of 
outputs that would be produced. In conjunction with 
questionnaire/ a schematic diagram of the system was 
the team's use. The statistics questions were keyed 
processing points on the diagram. All the libraries 
supply transaction volumes based on actual counts or 



th 1 s 
prepared for 
to 

were able to 
estimates. 



Estimated annual dollar costs. were calculated for each 
library by multiplying unit cost data for each type of on-line or 
batch transaction (supplied by Stanford) by the transaction 
volumes from each library. For each on-line or batch 
transaction/ a maximum (conservative) and a minimum (average; 
unit cost were provided. The final operating unit costs of the 
system will fall somewhere In this range. Final calculations 
were made using both maximum and minimum unit costs. However/ 
the summaries for each library were made using the maximum unit 
cost. In order to provide a conservative or worst-case cost 
estimate for management declston making. In BALLOTS/ the two 
typical on-line transactions are searching to locate a record and 
modifying a record by adding or changing data to produce a 
printed output. To reflect variation/ unit costs were calculated 
for simple/ medium/ and complex searches. Batch transactions 
produce printed library outputs and handle standing search 
requests against the MARC file. 

Equipment and computer overhead charges were not allocated 
on a per unit basis. Equipment costs are the charges for 
dedicated equipment used exclusively by an Individual user 
library. These Include the visual display terminal/ a modem/ and 
leased telephone lines. Computer overhead costs are the sizable 
fixed costs that Include the processing of major file updates/ 
charges connected with file storage/ and hardware connection time 
for the use of a small computer to handle communications between 
the terminals and the Stanford Computation Center 360/67. For 
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the purpose of this study, computer overhead was allocated 
proportionally to expected system usage (not the same for each 
library) and on the assumption that the four feaslbll 
participants plus Stanford would make up the network. Of course, 
Ifnorel Ibrarles Join the network, each library's portion of 
overhead will decline; If fewer libraries join the network, each 
library's portion of overhead will Increase. 

The next step In the study was to recalculate costs for all 
the functions affected by BALLOTS-MARC. After discussion, eight 
of the 12 functions were selected as the ones most likely to be 
affected by BALLOTS-MARC services. The four functions not 
affected were Claiming, Cancellation, Added Copies and Volumes, 
and Original Cataloging. 

Each of these eight functions was again dlagrammed--as It 
would be performed under manual-automated conditions. Standar 
time rates were used by all libraries for the new - Aarr hi ne an 
manual-automated activities (e.g.. Input at a CRT or sea, ^” n S * n 
on-line file). Equipment and computer overhead charges were no. 
allocated to Individual functions but added In at the library 
summary level. However, on-line and batch transaction charges 
were charged to the function for which they occurred. 

Thus, the costs for a function Involving BALLOTS-MARC were a 
combination of revised personnel and equipment costs for specific 
activities and of computing costs (on-line and batch charges;. 

The total of these new function costs, plus terminal equipment 
and computer overhead charges, was the cost to the library of 
using the BALLOTS-MARC system. The personnel costs were usually 
reduced because computer processing replaces some manual 
processing. Computer costs, however, were an added cost factor. 

The charges for on-line transactions, batch transactions, 
termtnal and associated equipment rental, and computing overhead 
make up the amount paid In dollars each month by each 
part IcI pat Ing In the network. In general, this Is an added cost 
to the library and represents added cash flow. But the 
difference between personnel costs under the current manual 
system and personnel costs under the manual -automated system is a 
function cost reduction that Is, In effect, a saving to the 
library. Personnel savings do not affect the cash flow unless 
there Is a net reduction In staff. Reassigning staff to new work 
Is a benefit to the library In terms of the added service 
performed, but does not help to reduce the cash flow. 

Reassignment must be evaluated separately by each library, ana 
may have an Impact on the decision to participate In a network. 



The Fea sibility Report 

At the conclusion of the study, a 250-page, 
was prepared and distributed to the directors of 



two-vol ume 
the four 



report 
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libraries. The report covered all four libraries. Volume 1 
contained two sections: general textual discussion of the purpose 
of the study, the BALLOTS-MARC system, and the [ brary . c ??J rarx/ 
analysis methodology, and a discussion prepared by each library 
that summarized the findings of the cost analysis for that 
library, advantages and disadvantages. Volume 2 comprised 
appendices containing the actual cost forms, calculations, unit 
on-line and batch transaction charges, and overhead cost 
calculations. No library was specifically named the report. 
The first section of Volume 1 was prepared by the BALLOTS start 
and approved by all team members. The second section was 
prepared by the team members of each library for their library. 

It was the purpose of this second section to discuss the cost 
Implications of using the BALLOTS-MARC system, the effects on the 
current system, and non-economic advantages and disadvantages. 
However, since no member of the team was In a library 
administrative position, this section did not attempt to offer- 
suggestions for obtaining funding for the new cash flow. Tb ® 
feasibility report is summarized In one volume for the benefit or 
additional potential network libraries (2). The summary contains 
the methodology, unit costs, and advantages and disadvantages 
from Volume 1 and the sample forms and calculations from Volume 

2 . 



The report did not attempt to draw overall cost and benefit 
conclusions from the studies done In these four 1 Ibraries. The 
report, we think, supplies the director of each 1 1br ? J y . . 

the quantitative data needed to evaluate the use of BALLOTS-MARC. 
the dollar decrease In personnel costs, the cost of on-line and 
batch transactions (maximum and average), the CRT equipment and 
associated equipment rental charges, and computer overhead. Of 
these costs, only the amount of computer overhead charged to each 
library Is affected by outside inf 1 uences— namel y, the number of 
libraries In the network. Everyone agrees that management must 
have cost data In order to decide whether to join a network or to 
undertake Independent library automation. It is obvious, 
however, that cost Is only one of many Items to be considered. 

The final decision Is based on a combination of factors, some of 
which are affected by the personalities of the people Involved, 
by the library, by the college or institution to which the 
library belongs, and by the state of the economy. Other concerns 
are morale, expectations of future benefit, augmented services, 
and the desire to reduce current inefficiencies and problem 
areas. The second section of the report covered not only cost 
but also these other non-economl c, intangible considerations. 



This study reflects an approach to planning for a network 
that deserves further exploration. The potential members of a 
network (the user libraries) need to know if It is to their 
advantage to join the network. For the most part they do not 
know how to ask questions that will give them this information. 



One approach is to hire a consultant. This may have the 
disadvantage of requiring a period for orienting the consultant 
to individual library operations and for training some portion of 
the staff in the consultant's "method." Also, a consultant can 
produce concern about change being introduced from without the 
library. 

The BALLOTS approach was to form a team of working 
librarians from all the libraries. The team developed the 
methodology and applied it. Since the team members had several 
years' experience in their respective libraries, they could 
efficiently secure the needed information and explain to their 
colleagues the purposes of the study. The study was completed In 
a relatively short time with no adverse staff reactions. Another 
effect of using a team of working librarians was to involve the 
library staff in automation decision making at the earliest Ci.e. 
feasibility) stage. For the administrator, the section of the 
report that his own staff produced, the data and the analysis, 
adds to the credibility of the report. 

Next 



To proceed with an on-line library network, a second 
workshop will be conducted with interested libraries. To follow 
the existing cost analysis and feasibility report, the next task 
Is to determine Individual user library requirements. These 
requirements will specify In detail any additions or 
modifications required by each library to BALLOTS— MARC CRT 
screens, outputs, services, etc. The output of the second 
workshop will be a Library Network Requirements document. This 
document will also include the detailed plan, schedule, and cost 
of training. Installation, and production operation for the 
network* Specific areas covered by the first workshop (such as 
Installing the BALLOTS-MARC system In the present manual system) 
will be treated In greater detail, and new areas (such as forms 
design and acceptance testing) will be examined. For new 
libraries Interested In Joining the network, an abbreviated 
feasibility workshop is planned, since the cost methodology, unit 
costs, and sample calculations are available. 

(i) lysism Sgaas. far Librax^ Automation, and 

General ized 1 nformatto-n, Retrieve 

at Stanford Un I vers I tv . SP I RES /BALLOTS Project, 

Stanford University, Stanford, California, 1970. 



(2) Montague, Eleanor, 

Summary £&. a Feasibility ?J <2R Ills. 
Participation oL lour. CoIleKea .and 
Universities la a Stanford UnlvqrsLJU m 
Library Automat 1 on Network. SPIRES/BALLOTS 
Project, Stanford University, Stanford, 

Cal 1 fornia, 1971. 
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(Note: each library Is charged on the basis of its individual 
total monthly transactions.) 
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ft A. ON-LINE TRANSACTIONS 

I 

§ A high unit cost and a low unit cost are given; the actual 

| measured results should fall somewhere between the two 

| unit costs. 



Transaction Type 


High 




1. Simple search 


$0.04 


$0.02 


2. Medium search 


$0.17 


$0.08 


3. Complex search 


$0.33 


$0.17 


4. Simple Input 


$0.10 


$0.05 



B. BATCH TRANSACTIONS 

All printed outputs are figured at a high unit cost of 
$0.04 and a low unit cost of $0.02. In addition, each 
printed output Involves a $0.02 print charge, making the 
effective high and low unit costs $0.06 and $0.04. 



C. DEDICATED EQUIPMENT CHARGES (MONTHLY) 



1. Terminal rental (stand-alone terminals) 

2. Terminal rental (clustered terminals) 

3. Data set rental* (one per terminal) 

4. Leased tel ephone 1 1 nes** (one per terminal 



1 ease $225. (ea. ) 
lease $155. (ea.) 
lease $ 50. (ea.) 

1 ease $ 3. (per ml . ) 



* Stanford wl 1 1 purchase data sets so the on going cost will 
be el Iml nated. 

** Libraries on the Stanford campus do not pay telephone line 
charges since lines have been purchased. 



Unit Costs of Computer Transactions for BALLOTS 
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Figure 8 



1. Purchase Orders - 24,800 

2. Abel Slips (Abel Original Invoice, Abel Accounts 
Receivable) - 15,000 

3. NPAC (National Program for Acquisitions and Cataloging'!) 
Notices - 4,000 

4. Process Slips (no accounting for multiple copies) - 5 

5. Statistics Reports (Acquisition and Cataloging) - 12 

6. TI tie II SI ips - 4,250 

7. Catalog Data Slips - 47,250 

8. Requester Notices - 32,500 

9. Claim Notices - 7,500 

10. Cancellation Notices - 750 

11. Claim Listings - 52 

12. Cancellation Listings - 52 

13. invoice Claim Listings - 52 

14. Invoice Claim Notices - 3,750 

15. Claim Errors - 52 

16. Requests for Books In Process - 1,500 

17. Catalog Cards - 500,000 

18. Spine Labels (2 per book) - 110,000 

19. Book Cards - 55,000 

20. Reference Cards - 13,000 

\., k 

21. MARC Purged Standing Search Requests - 2,740 

22. MARC Standing Search Requests Matched Records ~ 14,520 

23. MARC Data Slips - 250 
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Figure 9. Stanford Full Automated System Annual Printed Outputs 
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Figure 10. Stanford Full System Technical Processing Load (by Screeii UljeJ 



(Note: higher unit cost used in calculations) 



TYPE OF TRANS- 


UNIT 


BAULOTS 


-MARC 


FULL BALLOTS 


ACTION OR CHARGE 


COST 


MODULE 


COSTS 


SYSTEM 


COSTS 


A. On- 1 ine_ transact ions; 


f 


no . of 




no . of 








trans.. 


cost 


trans,.- 


cost 


1. Simple search 


f 

$.02/. 04 


35 


$ 1.40 


800 


$ 32, 


2. Medium search 


.08/. 17 


90 


15.30 


300 


51, 


3. Complex search 


.17/. 33 


42 


14.00 


2i0 


6 


4. Simple input 


.05/. 10 


174 


17_._40 


1.200 


120 


DAILY SUBTOTAL 




341 


$48.10 


2,32* 


$209 


MONTHLY SUBTOTAL 




7,500 


$1,060. 


51,000 


$4,6i 






no. of 




no. of 




B. Batch transactions: 




docs. 


cost 


docs. 




1. P.O.'s 


$.02/. 04 


54 


2. 16 


160 


$ 6 


2. Cards 


«l 


833 


33.32 


2,054 


82 


3. Labels 


II 


249 


9.96 


44 


18 


4. SSR's match & 












purge 


II 


236 


9.44 


69 


3 


5. Title II slips 


II 


0 




17 


1 


6. Process slips 




326 


13.04 


362 


14 


7 . C 1 rc. punched 












cards 


II 


0 




220 


9 


8. Misc. forms 


SI 


0 




48 


2 


CPU SUBTOTAL 




1,698 


$67.92 


3,370 


$135 


Print charges 


$.02 




$33.96 




$ 67 


DAILY SUBTOTAL 




1,69* 


$101.** 


3,370 


$202 


MONTHLY SUBTOTAL 




37/356 


$2, 241. 


70,200 


$4, 2 



Figure 11. 



BALLOTS Cost Calculations (continued 
on next page) 
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(Note: higher unit cos’’ used in calculations) 



TYPE OF TRANS- 
ACTION OR CHARGE 



UNIT 

(TOST 



BALLOTS-MARC 
MODULE COSTS 



FULL BALLOTS 
SYSTEM COSTS 



O 

ERIC 



C. Dedicated eauioment 
charges i: 


amount 
of I tern 


cost 


amount 
of i tem 


cost 


1. Terminal rental ($15 5 /mo.) 


3 


$465. 


15* 


$2,330. 


2. Data set rental 


0 ’ 


(purch . ) 


0 


('purch . ) 


3. Dedicated line 
MONTHLY SUBTOTAL 

D. Overhead charees: 


0 


(ourch. ) 


0 


fmrrch . ) 


amount 
of i tem 


$465. 

cast 


amount 
of item 


$2,330. 


1. Batch util. & 
file update 




$3/630. 




$7, 000. 


2. File storage 
($l,200/disk) 


1 


1/200. 


7** 


8,400. 


3. Connect time 
($3. 50/hr. ) 


176 


615. 


176 


615. 


4 . C i rcul at ion 
computer *** 

MONTHLY SUBTOTAL 

TOTAL MONTHLY COMPUTING COST 
TOTAL ANNUAL COMPUTING COST 


0 




1 


(ourch. ) 




$5/445. 

$ 9/ 211. 
$10/532. 




$16,015. 

$27,155. 
$325, 860 



* Clustered terminals. 



** Storage costs: 6 disks the first year and 1 disk added per year 
(CDF); 1 disk added for Circulation. 



♦♦♦Assumes minicomputer purchased for Circulation transactions/ but 
disks and terminals still leased (no additional on-line charges 
involved). 



Figure 11. (continued) BALLOTS Cost Calculations 
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telephone Hne is a function of the distance from Stanford 
Uni vers tty . 

The computer system overhead charges include the cost of 
file storage (i.e., storing the MARC file and the In Process 
File, etc.). The file update costs Include the costs of reading 
and converting the weekly MARC tapes and adding this data to the 
on-line MARC file. Also Included in these file update costs are 
the costs associated with updating individual records that are 
changed by the library during the course of the dally activity. 

The on-line coimect cost is a ■fixed cost per hour for connecting 
the terminal to the Campus Facility computer. From Figure 11 it 
was determined that the costs due to on-line and batch transactions 
(A. plus B. ) represent only 32 percent of the entire operational 
cost of the full system. The rough calculation shows that adding 
enough network libraries to the system to double the system 
throughput (the total of on-line and batch transactions) would 
double the cost of on-line and batch transactions (A. plus B.) and 
presumably double the cost of terminals (C.), while leaving the 
computer system overhead charges CD.) roughly the same. According 
to the data In Figure 11, the monthly cost for the Stanford full 
system excluding overhead charges is $4,600 (A.) plus $4,210 (B.) 
plus $2,330 (C.), totalling $11,140. Adding network libraries to 
double the amount of on-1 ine and batch activity would mean an 
additional monthly cost of $4,600 (A.) plus $4,210 (B.) plus 
$5,180 (C.), totalling $13,990. The dedicated costs for network 
libraries Include data set rental, line costs, and the unclustered 
(stand-alone) terminal costs. (The stand-alone terminal cost, 

$225 per month, was used in this calculation because many small 
libraries wtll find that clustered terminals do not suit their 
operations.) $11,140 per month for Stanford and $13,990 per 
month for network libraries plus $16,015 for the overhead 
charges (D.) plus $2,000 additional update and storage equals 
$43,145 per month. Dlvldtng this cost by 140,400, the number 
of documents produced monthly (70,200 times 2), yields a cost 
of $0.31 per document. Comparing $0.31 with $0.39 and $43,145 
with $27,155 indicates that a substantial reduction in unit 
costs can be achieved by increasing the system activity. 

While one is increasing the monthly operating costs by 59 percent 
(from $27,155 to $43,145), one ts also doubling the system output 
and decreasing the unit cost of a document by 20 percent (from 
$0.39 to $0.31). 



3.9 NET COST OF LIBRARY AUTOMATION 

One of the major unknowns in cost calculations Is the total 
number of libraries participating tn the BALLOTS network. Since 
the overhead cost is the major factor tn the cost calculations 
and In the ultimate costs to the various libraries, the more 
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.Most of the cost figures used In the report are of necessity 
calculations, not measurements of actual production operation 
costs. Until the system has been In operation for several months 
It wHi not be possible to arrive at accurate costs. In 
determining the met cost of library automation, many factors not 
yet mentioned must also be taken Into account. 

One of the considerations to keep In mind In the area of 
manual savings In the library Is the fact that although it may be 
possible to save a substantial amount of manual activity, this 
savings In time carmot be translated to cash flow dollars by the 
library unless tire positions affected are eliminated. Most 
libraries feel that attrition would be the only way to reduce the 
present staff, and this Is a relatively slow process. Savings 
that appear as fractional personnel would probably result In 
reallocation of assignments to provide better service. Until 
attrition could eliminate a full position or more, to offset 
Incremental costs of operating the automated system, the actual 
cash flow would not reflect any savings. It Is for this 
reason that the calculations for cost savings due to library 
automation are gradually obtained over a period of several years 
rather than Immediately on successful Implementation of the 
system. One factor absent from these cost calculations was the 
Increased cost of labor. The net Increase In salaries for 
various libraries averages from 4 to 10 percent per year. 

If It were possible to add these factors Into the cost 
calculation, the net coi,t of library automation would appear 
somewhat less expensive. 
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CHAPTER 4 



ACTIVITIES FOLLOWING THE REPORTING PERIOD 
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4.1 IMPLEMENTING THE BALLOTS-MARC MODULE 

Several activities are now underway or in the planning 
stages to prepare for the actual dally operation of the BALLOTS 
system— f I rst at Stanford/ then In’ the CLAN libraries. Almost 
all of these activities support the operation of the first 
module/ BALLOTS-MARC. 

Under the BALLOTS system/ a new module may require creating 
a new on-line file or adding additional applications software to 
support an existing file. In either case/ the Implementation of 
a module requires Integrating and coordinating six major systems 
analysis tasks and three major programming tasks. (The numbers 
following refer to Figure 12.) The systems analysis tasks are: 
(1) determining system requirements/ (2) preparing representative 
test data/ (3) preparing training and user manuals/ (4) 
acceptance testing/ (5) user training/ and (6) pilot production. 
After (7) requirements review/ the programming tasks are (8) 
programming (Including design/ coding/ testing/ and documenting)/ 
(9) system acceptance testing/ and (10) pilot production. 



These systems analysis and programming tasks are carried on 
In parallel In the following way to move the module towards 
Implementation. (Again the numbers refer to Figure 12.) (1) The 
library analysts prepare system requirements jointly with the 
library and secure the library's approval. (7) These 
requirements are passed on to the programming staff for review as 
to their clarity/ consistency/ and design feasibility. While 
this review Is going on, the analysts and programmers discuss the 
requirements and the programming to be done/ and (2) the analysts 
begin preparing representative test data. After the requirements 
are given technical approval/ (8) programming begins. After 
design/ coding/ and preliminary debugging/ the test data are used 
with the new programs. While programming Is being done/ (3) the 
analysts plan user training and prepare training material. Using 
documentation prepared by the programmers/ prel Imlnary vers Ions of 
user manuals are written. When programming Is completed/ (9) the 
programmers begin system testing while analysts (4) perform an 
acceptance test and (5) train user supervisors; then the library 
supervisors perform an acceptance test. User manuals are 
revised/ (5) the full library staff Is trained/ and (6)/ (10) 
pilot production begins. System testing continues throughout 
pilot production and Into the first few weeks of full production. 
Maintenance documentation Is put In final form by the programming 
staff at the end of pilot production. 
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Figure 12 • BALLOTS Module Implementation Tasks 



A typical cycle of implementation tasks takes from 5 to 52 
weeks depending on the module's complexity and the manpower 
assigned to the task. The first module and one of the largest s 
BALLOTS-MARC. BALLOTS library analysts and programmers are well 
Into the BALLOTS-MARC Implementation activity as this report is 
being produced. The ability to meet the projected schedule and 
to maximize the use of staff and hardware (and thereby to proceed 
most economically In a cost benefit sense) depends on external 
funds to support the completion and Implementation of the BALLOT 
modules during 1972 and 1973. 



The library analysts are now writing Instructional manuals 
for the users : the training and procedures manuals. The training 
manuals will give the basic background Information Including an 
overview of the system, as well as the technical knowledge 
required to operate the video terminals and use all of the 
various screen formats. The procedures manuals will show how the 
library's manual, procedures are adjusted to allow the automation 
system to become part of the day-to-day environment of the 
library. The location of the video terminals In the Stanford 
Main Library has been determined and the communication lines are 
being Installed. Once the terminals have been Installed, the 
library analysts will check them out and begin user training In 
the Library. 



The BALLOTS programmers are completing the check-out of the 
BALLOTS subprocessor (see section 3.3) for the BALLOTS-MARC 
module. The CRT screen formats are being coded and checked out. 
In addition, the output documents required for the first module 
will be produced and checked. 



Following this analysis and programming work, the acceptance 
testing, user training, pilot operation, and full operation will 
be conducted. 

As described In the concluding paragraph of section 3.1.3, 
the Stanford Computation Center Campus Facility made a commitment 
to BALLOTS 0 Implementation via a "front-end" minicomputer Into 
MILTEN, the 360/67 communications subsystem, and ORVYL, the 
360/67 time-sharing subsystem. This commitment meant ordering 
and Installing additional hardware at the Campus Facility and 
making software changes to accommodate BALLOTS. Both 
activities are being carried out. 



4.2 MODULES FOLLOWING BALLOTS-MARC 

Following the production operation of the Implemented . 
BALLOTS-MARC module, each of the other ten modules described In 
section 2.3 will be Implemented In turn. Figure 13 shows the 
screen formats, the flies, and the Inputs and outputs that will 
be added to the BALLOTS system with the addition of each module. 
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During the pilot operation of each module, the library analysts 
and library supervisors will monitor and audit the system 
continually. Debugging, fine-tuning to optimize the system, and 
minor modifications to make the system more convenient and useful 
to the library will also take place during pilot production. 

When the library Is satisfied with a module. It will be 
considered In production status, allowing the analysts and 
programmers to concentrate on the next module. Since the time 
for acceptance Is determined by the library and Is therefore a 
development variable, the Implementation dates for each module 
may vary from the schedule date. If the development work for a 
module Is completed ahead of schedule, the library will have the 
opportunity to Implement the module earlier than scheduled. 

As can be seen In Figure 12, the parallel progress of tasks 
towards completing a module Is such that one group may be free to 
turn to other work while another group Is working on the module. 
Thus the library systems analysts used the period between 
BALLOTS-MARC requirements definition and users' manual 
preparation to compile the requirements documentation for the 
following module, MARC-IPF, and submit the document to the 
1 Ibrary for approval . Once a module Is In production operation, 
the programmers can turn to the already documented and approved 
requirements they need In order to begin their work on the next 
module. 



4.3 EXTENDING MODULES TO NETWORK LIBRARIES 

For the first four to eight months after a module has been 
Implemented and placed In production. It will be closely observed 
and monitored. During this period, the network version of the 
module will be checked out and tested for network use, and the 
network libraries will Install equipment and conduct training 
classes and acceptance tests. When this Is completed, the module 
will be put Into network pilot production. Thus a module will 
have four to eight months of heavy production use In Its original 
version prior to network Installation. This will reduce 
Implementation time and effort for the network users. 
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"The CLSD project, ff viewed within the context of 
the original objectives and the perspective of the 
emerging state-of-the-art characteristic o^ the late 
60's, was an extremely beneficial experience for those 
who participated, and to a lesser degree, the general 
library community. Though the findings of the project 
were often negative, these facts in themselves are 
important because they helped the participants (and, 
one hopes, to some degree, the general library 
community) to distinguish between the practical 
realities of library systems development and the 
popular misconceptions of the totally automated 
1 i brary. 

"Based on the experience gained in the CLSD 
project, the following observations are offered: 

a. Loosely defined, cooperative projects, such as 
CLSD, though beneficial for those participating, 
are not the best or even, perhaps, the most 
efficient ways of fostering collaborative work. 

b. Cooperative work would have had more chance to be 
successful If done on a local level. The 
logistical problems of convening personnel 

from widely separated institutions are 
formidable and time consuming. 

c. Cooperative work needs a strong commitment on both 
a technical and administrative level from all 
participants. The nature of the commitment must 
be clearly stated and fully understood. 

d. . Coordination of local development and work 

schedules Is difficult to achieve. Detailed 
coordination of schedules is probably impos- 
sible to achieve among several independent 
projects. A truly joint effort probably 
requires that a single work schedule be 
developed and adhered to. This is probably 
possible only where there is agreement among 
the participants that a single program package 
will be developed and all local processing 
systems will use either a centralized process- 
ing facility or radically redesign local 
procedures to conform to the requirements of 
the program package. 
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e. Rapid communication and detailed documentation Is 
vital to a systems project. There Is no simple or 
practical method of insuring that communication 
and documentation Is done effectively within 

a single Institution. The problem Is enorm- 
ously aggravated in an Inter- Inst I tutional 
effort . 

f. Computer hardware configurations have played and 
probably will continue to play an important and 
decisive role in the design' of library systems. 

Large scale, compatible computer systems for 
libraries are not yet technically feasible. 

g. Standards are lacking in many areas of library 
systems work. Until standards are established, 
library systems design efforts will continue 

to result in unique processing systems reflect- 
ing the peculiarities of local environments, 
thereby reducing the possibility of developing 
transferable systems. 

"Large scale library systems work is just now 
begining to emerge from a period of pioneering and 
research. In the next several years, practical, 
production-engineered Systems will begin to be made 
available and used. The cost of developing such 
systems is enormous; therefore, few individual 
libraries will be able to afford to develop systems for 
themselves. The feasibility of libraries being able to 
cooperatively develop large scale, complex, 
transferable systems on an informal basis is dubious. 

At present, there are other, more promising approaches; 
these include: 

1) local, joint efforts for the cooperative 
development of similar and compatible systems 
wherein participating libraries are financially 
and administratively committed; 

2) cooperative effort for the development of a 
single, central or regional system wherein, 
again, participating libraries are financially 
and administratively committed; 

3) centralized development of a general-purpose 
library package, with options for customer 
mod if Icat ion ." 

The CLSD report acknowledges the problems associated with 
each of these three approaches to development, and in particular 










109 

113 



i 



suggests that although generalized systems exact a certain 
penalty in reduced efficiency, they facilitate networks by 
preserving enough local autonomy to ensure political viability. 
One thing about networks is quite clear in the United States: no 
network can dictate its design and services to its intended 
clientele. It is for this reason that a strenuous 
user- i nvol vement effort has been undertaken in CLAN--to make 
certain that the available applications work to the satisfaction 
of thei r users . 

(Taken from: COLLABORATIVE PROGRAM IN LIBRARY SYSTEM DEVELOP- 
MENT: FINAL REPORT, A Report to the National Science Foundation, 
NSF-GN-724, July 1971, pp. 19-20.) 
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THE ORDERING PROCESS 



REQUESTS 

Material Is acquired for the Stanford University Libraries by 
two prlnlcpal methods: (1) generating a purchase order in response 

to a specific request for a title,, and (2) receiving a physical 
volume through an approval or blanket order plan, from an overseas 
buying trip, by exchange, or as a gift. 

The ordering process handles the acquisition of specific material 
by purchase order. Organizationally, the ordering process is 
centrally coordinated by the Stanford University Libraries 
Acquisition Department Order Division. 

Requests arrive for order processing from faculty, staff, students, 
library departments. Coordinate libraries, and other users of the 
centralized ordering process. The process provides three services 
to its users: (1) pre-orderlng searching. If required, (2) creation 

of an In Process File record for a title to be ordered, and (3) 
production from the In Process File record of all documentary outputs 
required In ordering. 

SEARCHING 

Requests for which pre-order searching is not required are 
Immediately keyed Into the In Process File. All other requests 
are searched for before a purchase order Is generated. The purpose of 
this search is to: 

(1) Verify that the requested title Is not an unneeded 
duplicate of a title currently held, in process, or 
expected on approval. 

(2) Verify the bibliographic description of the title in 
order to communicate accurate Information to the vendor 
on the purchase order. 

(3) Locate Library of Congress bibliographic Information for 
new acquisitions to communicate accurate information to 
the vendor on the purchase order and to speed cataloging 
once the material Is received. 

ON-LINE FILES 

In addition to the standard printed reference tools, catalogs, and 
Stanford's manual files, four on-line computer files are available 
for searching: 

The In Process File - the central control file for all 
titles in process. 

The MARC File - the Stanford file of Library of Congress 
MARC records, 

- B - . 
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The Meyer Inventory File - the central file of bibliographic 
and circulation records for the Meyer Memorial Library. 

1 The Catalog Data File - a central file of bibliographic 
records for titles processed through the automated Cataloging 
Subsystem (not Including Meyer titles). 

These files are searched at a cathode ray tufc>e (CRT) visual 
display terminal. Bibliographic data can be copied from the MARC/ 

Meyer/ and Catalog Data Files Into the In Process File. 

IN PROCESS FILE RECORDS 

The In Process File contains bibliographic and acquisition 
data for all titles on order. A title can be acquired by different 
methods (e.g./ gift/ purchase order/ approval)/ from different 
sources, at different times. A single bibliographic record may have 
associated with It several separate acquisition records. Each 
' bibliographic record has an acquisition record for each order of 

the same title. 

I, An In Process File record Is created In three ways. During pre-. 

I order searching/ If b I bl I ograph i c l nformat I on Is found for the title in 

| MARC/ Meyer/ or the Catalog Data File/ the Information Is transferred to 

the In Process File/ coupled with new acquisition Information that has 
i been keyed at a CRT/ to form a new record. If bibliographic Informa- 

tlon Is already In the In Process File/ only newly keyed acquisition 
I .) Information Is added to form the new record. If no machine-readable 
E'"' data Is found/ both bibliographic and acquisition data are keyed at the 
| terminal to create a new In Process File record. 

| DOCUMENTARY OUTPUTS 

I 

I When the In Process File Is updated with a new acquis! ton record/ 

f Information for all ordering documentary outputs required for the 

g title Is extracted and sent to the output print program for overnight 

§ sorting/ formatting/ and printing. Ordering outputs are: 

Purchase Order - sent to the vendor to order a specific title. 

Dealer Report - sent with the purchase order to be returned 
by the vendor with the material/ or used as a report If 
the order cannot be filled. 

Abel Accounts Receivable Slip - sent with the purchase 
order If Abel Is the vendor. Used for Abel 's Internal 
process l ng. 

Abel Original Invoice - sent with the purchase order If Abel 
Is the vendor. Returned with the material as an original 
Invoice. 

Process Slips - sent to a user of the ordering process who 
maintains a manual file for his own internal processing. 

NPAC Notice - sent to the Library of Congress for each title 
In the scope of the National Program for Acquisitions and 

Cataloging for which no Library of Congress bibliographic 
data was found during the ordering process. 
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PURCHASE OROER MATERIAL RECEIPT PROCESS 



Materials (physical volumes) here Included are those that 
are received In the Acquisition Department Order Division (1) accompanied 
by a dealer report slip* (2) represented by a purchase order / or (3) 
routed from Serial Division check-ln. 

The only bibliographic searching performed In the purchase 
order material receipt process Is as follows; 

1. MARC search for a monograph In a series on standing 

order that Is to be classed separately (not done In the current 
system) ; 

2. Search of the National Union Catalog and reference tools to 
establish more accurate entry for certain Slavic materials. 

The In Process File and the MARC file are the only files 
used In this process. The bibliographic or acquisition Information 
contained In an I PF record may require other updating at the time of 
receipt besides the addition of material receipt Information. 

New I PF records may be created for a series on standing order 
prior to automation that Is to be classed separately* and 
for an Individual monograph belonging to sueh a series. 

Bibliographic data may be copied Into the In Process 
File from the MARC rile. 

Three printed outputs are produced as a result of the purchase 
order material receipt process; 

1. Catalog Data SI I p--conta Ins bibliographic data* shelving 
location* and other Information needed by the cataloger* 

Inserted in the material for routing to the Catalog 
Department. 

2 . Title II Slip — Inserted In the material and sent to the 
Catalog Department for filing I“*"‘ the Title II File If 
Library of Congress catalog dai in manual form Is expected. 

3. Requester Notice — sent to requester to notify him that 
requested material has been received. 
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DISTRIBUTION AND MARC SEARCHING PROCESS (CT.DIS) 



y 

The central distribution section within the Catalog 
Department receives from the Acquisition Department material 
ordered through the automated Acquisition Subsystem# along with a 
Catalog Data Slip (GN.SYS.CD01)# a Catalog Data Slip Copy 
(GN.SYS.CD02)# and a Title II Slip (GN.SYS .TT01) if applicable. 

It receives material ordered through the manual system along with 
one to three copies of an SUL-7 form {'CT.DIS. SUOl)# and perhaps 
a book requisition (AQ.SEL.BR01) and/or a Title II card 
(AQ.ORD. LC01). Messenger slips and slips indicating added copy# 
added volume# and serial analytic come with the material as 
needed. Serial analytics are accompanied by a Charge Slip 
(CT.DIS. CS01). 

Material will be distributed as follows: 

1. Material requiring original cataloging: If 

the material is for stack# reference room# 
graduate program in humanities# Catalog Department 
collection# or modern 

European languages# the I PF record is updated 

to show the first one or two letters of a 

tentative LC classification (used for counting 

arrears and for locating uncataloged material)# and the 

material then is sent to the 

cataloger for Original Cataloging (CT.ORG). 

If the material is for other locations# It is 
sent directly to the cataloger (CT.ORG). 

2. Material for which LC data is expected: this is placed 

In the holding area in ID number sequence# and the 
Title II slip filed. 

3. Material for Meyer Library: this is placed in the 

holding area in ID number sequence if LC data 

is expected# and held up to two months. Otherwise It is 
sent to Meyer Cataloging (CT.MEY). 

4. Overseas campuses material: this is sent to Overseas 
Cataloging (CT.OVS). 

5. Added copies# added volumes# and replacement copies: 
these are sent to Added Copies/Volumes (CT.ACV). 
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6. Material for which LC data has been found: this is sent 

t to LC Cataloging (CT.LCC). 

7. Purchase order material for which MARC data Is expected: 
the distributor searches the MARC file. If he does not 
find MARC data,. he creates a MARC standing search 
request and puts the material in the .holding area; if he 
finds MARC data, he transfers it to the IPF, and a MARC 
Data Slip (GN . SYS . MD01-02 ) is created and matched with th 
material, which is then sent to CT.LCC. 

8. Material that needs an NPAC notice, a standing 
search request for MARC data, or a Title II Slip: 
the IPF record is updated to produce the required 
output; and the material is placed in the holding 
area. 

The distribution section receives a weekly Matched Records 
Listing of the ID numbers of titles for which MARC data has been 
found on a MARC tape during MARC Processing (TP. MAR). The 
distributor verifies the match by calling up the IPF record and 
the corresponding MARC record on a CRT screen (GN. SYS. BF01) and, 
for successful matches, initiates the transfer of data from the 
MARC File to the in Process File. The I PF record Is updated 
automatically as part of the transfer operation to show 'MARC 
data found." As a result of the transfer, a MARC Data Slip 
(GN.SYS.MD01) and a MARC Data Slip Copy (GN . SYS.MD02 ) are 
produced and matched with the material, which then is sent to LC 
Cataloging or Meyer Cataloging. 

If a Title II card (AQ.ORD. LC01) is found while filing Is 
being done in the Title II File, the card and the Title II Slip 
(GN.SYS.TT01) are pulled and matched with the material being held 
In the holding area. (If the material is for Meyer, the Title II 
card is not pulled; the Tttle II Slip is annotated to show the 
presence of a Title II card and placed with the material.) The 
IPF record is updated to show "Title II card found" and the 
material Is sent to LC Cataloging or Meyer Cataloging. 

The distribution section receives a monthly Out of Date 
Standing Search Requests Listing (GN.SYS.OLOl) of the I terns for 
which MARC or Title II data has not been found during the 
designated holding period. The material is pulled from the 
holding area and previous searching is updated as necessary 
(Including a final on-line search of the MARC file). The IPF 
record is updated with the tentative class number, if necessary, 
and the material is sent to Original Cataloging or Meyer 
Cataloging, or to LC Cataloging if LC data was found while 
searching was being updated. 
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The Out of Date Standing Search Requests Listing does not 
include material ordered under the manual system. Such material 
Is shelved in the holding area by date of receipt and pulled at 
the end of the holding period as in the current manual system. 

Bulk acquisition material Is received by the central 
distribution section from its source; it does not go through the 
Acquisition Department, and has no I PF record. This material is 
manually controlled and distributed for Original Cataloging. 

This manual procedure is not shown on the CT.DIS flow chart. 

When the distribution section receives Catalog Requests 
(GN.SYS.RC01 and GN.SYS.RC02) and Requests for Book in Process 
(CT. D I S . RB01 ) , the distributor must determine the location of the 
material within the Catalog Department. (If the request does not 
give enough information to locate the item, an I PF search may be 
made.) If the material has been distributed for cataloging, he 
notifies the cataloger that the request has been received and 
that the material should be cataloged on a priority basis. If 
the material is in the holding area, he pulls It and pulls the 
Title II slip if necessary. He updates the I PF record with the 
temporary classification and gives the material to the cataloger 
(CT.ORG or CT.MEY) . 

Material that is not received by the central distribution 
section and thus does not follow the flow outlined above will be 
handled in a similar fashion by the appropriate units as 
described below. 

1. Music materials ordered through the Automated system: 
these are sent with Catalog Data Slips and Title If 
Slips by the Acquisition Department directly to the 
Music Library, where they are distributed within 
the Music Cataloging Section to Original Cataloging, 

LC Cataloging, or Added Copi es/Vol umes, or placed In 
a holding area to await LC data. The Title II Slips 
are filed in the LC Card File in the music 
library. If a Title II Card Is 

found there, it is pulled and placed with the material 

that is sent to CT.LCC. In this case the I PF 

record is not updated to show that LC data has 

been found. If MARC data is found for Music 

material, the transfer of data to the I PF Is 

done at the Main Library and the distribution section 

send the MARC Data Slips to the music Library for 

matching with the material, which then is sent to CT.LCC. 

If MARC data is not found during the holding period, 

the distribution section sends the monthly Out of Date 

Standing Search Requests Listing for Music items 

to the Music Library so that the Music Cataloger 

may pull the material from his holding area and 

distribute it for Original Cataloging. 



2. Special collections materials: these are sent 

directly from the Acquisit-ion Department to 
Special Collections/ where they are distributed for 
Original Cataloging or LC Cataloging. 

3. PL480 program materials from Yugoslavia (no I PF 

record): these are received in the Slavic unit with a 

PL480 Mimeographed Card (CT.DI S.M001) . The card is 
filed In the Title'll file and the material is held in 
the Slavic Cataloging unit. If a Title II card is 
found, the distribution section sends it the the Slavic 
unit. No automatic notification of the end of the holding 
period Is provided. 

4. Serial titles new to Stanford University Libraries: 

these titles are received In Serial Records, where they are 
matched with the Process Slips (GN.SYS. PS01 ) produced 
at the time of ordering. They are then sent to the 
Serials Cataloging unit, where they are distributed. 
Material requiring Original Cataloging is sent to the 
appropriate cataloger (CT.ORG); material with LC data 
Is cataloged in the Serials unit (CT.LCC). If Title 
II data is expected, the material is kept in a holding 
area and searched repetitively in the Title II file. 
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THE MEYER CATALOGING PROCESS ( CT.MEY ) 

'h 

ifie purprose of the Meyer Catalog!! nsg process (CT.MEY) Is to 
prepare and maintain catalog records for the material cataloged for 
the Henry Meyer Memorial Library. Except in the distribution 
of material, this process is separate from the other Catalog 
Department processes. The separation has proved to be an 
efficient allocation or personnel since Meyer ‘uses different 
cata'Ioging rules and formats, and since maintaining a catalog in book 
form necessitates different approaches and techniques. 

Most Meyer materia’' will be received in the Catalog 
Department through Che Distribution Process (CT.DIS). Material 
for which an In Process F"le ( I PF 3 record has been created 
already and for which MARC data is expected will be placed in the 
Catalog Department holding area, to he held no longer than two 
months. During the holding period the titles will be searched 
automatically against each weekly MARC tape; when matches are 
discovered, CT.DIS wi 1 1 forward the material to CT.MEY. The MARC 
records that are transferred to the I PE as a resul t of this 
matching are also printed out on two-part MARC Data Slips 
(GN. SYS.MDOl-0’2 ), and inserted in the material before it Is. 
forwarded. 

Material for which no MARC data is expected, or with which no 
MARC data has been matched after two .months, will be sent to 
CT.MEY with a printout of the f PE record on a two-part Catalog 
Data Slip IGM.SYS.CO 01- 02). 

Material ordered (before t!he imp! eraentstimn of the Acquisition 
Subssssterrr and received after the imp! em*entstion o* CT.MEY 
will not have IFF records.. Any such ittera wtlT be sent to 
CT .ME - ' accompanied by an SUL - 2 5 form (A'n.BFRD . R.R01) and/or the 
green copy from the SUL-7 form ( CT. D I S^S 13-0X3 . In time this 
category of material will! diminish and eveiwtua 1 1 y disappear. 

Gifts selected by the feyer reference staff for addition to 
the -LEirde rgrad.ua te 1 library wf 1 1 be received In CT.MEY with 
two-part Catalog Data Slips., since the Gift Division will have 
creatred the requisite I PF records. 

Tor most (hooks Intended for Meyer Reserves, an 1 PF record 
will already have been created by the Order Division before the 
bo#ks are received in CT»MOT. A few books*— wh i ch are needed on 
such short notice that there is not time for Order Division 
processing — w^ll be received in CT.MEY without 1 PF records. 

r^eyer phonodiscs and tapes will continue to go to the Audio 
Library. After a sequential number is assigned there, the 
material will be transferred to CT.MEY for cataloging. The 
Order Division wi U 1 not enter phonodiscs or tapes into the BIPF. 
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After material has been received in CT.MEY, it will be sorted 
(CT.MEY. 01) according to cataloging, priorities and source of 
bibliographic data. After sortlrrg and prior to cataloging, all 
material will be searched In the Meyer Inventory File (INV.; anc 
depending on the source of the bibliographic data on the 
accompanying process slips* dixferent data elements will be 

checked. 

% 

If the source of the bibliographic data for new material 
being searched is the Library of Congress (either captured from^ 

MARC or keyed Jn by the Order Division from a Title il LC depository 
card or an LC printed catalog entry), then the entry, call number, 
subject and other added entries can be checked against the IWV or 
compatibility. If the source of the bibliographic data is not 
LC, then only the designated entry or alternative entries can be 
checked for compatibility with the INV. 

items marked as added volumes or copies on their process 
slips will be checked against the corresponding INV record. If 
this search shows that the item is an added volume or copy, ft 
will be sent to the added cooy/volume procedure. If 
searching shows that an item is not an added copy or volume as 
indicated on its slips, ft will be treated as new material. 

If the search shows that a supposedly new Item Is actually an 
added volume, it will b® sent to the added copy/volume procedure. If 
the search shows that a nsv? item is an unexpected duplicate, the Meyer 
reference staff will be asked it they want it added to the collection. 
If they do. It will be sent for added copy/ volume processing. Ilf 
the Item is not wanted,, it will be returned to the Order Division. 

Following 'the intial search in the INV, material will be sent 
to one of fotur cataloging procedures: 

1. Added Copy/Volume processing (CT.MEY. 07). Material 
to be added to existing holdings, excluding unwanted, 
unexpected duplicates. 

2. LC Cataloging (CT.MEY. 04). Material with I PF records 
created from LC information. 

3. Original Cataloging (CT.MEY. 05). Material with ! PF 
records created Ifrom other than LC information. 

4. Cataloging without I MV or I PF records (CT.MEY. 12). 

Material ordered under the manual system and therefore 
without I PF records. Also will cover rush Meyer reserve 
material not processed by the Order Division. 

In added copy/ volume processing ( CT. MEY'. 07 ) , a copy 
(This can be done Immediately after the initial search 
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by keying a transfer command on the search results screen.) The 
update is then keyed into the IPF, together with a command to 
copy the updated record back into the I NV . As a result 
the I NV wi 1 1 be updated. Spine labels, a book card, 
and a Meyer short card also will be generated. 

During LC Cataloging, Original Cataloging,* or cataloging 
without INV or IPF records, any of the system files may be 
searched for information. The IPF can be queried for information 
about the status of related items. The INV file can be checked 
to see how personal, corporate, or conference names and subject 
headings have been established and if an assigned call number is 
unique to the INV. (This step will replace the searching 
currently done in the Meyer manual authority files and the shelf list.) 

The Catalog Data File (CDF) can be searched to see if a title has 
already been cataloged for the main library. The MARC (MRC) file 
can be searched to see if a matching MARC record Is available. 

If a matching record is found, it can be copied to the IPF 
for updating. If the source of the bibliographic data in this 
record is LC, the material is routed to the LC Cataloging 
procedure (CT.MEY.04). If the source of the bibliographic data 
is other than LC, the material is routed to the Original ; 

Cataloging procedure (CT.MEY.05). 

5 

If an IPF record exists, it will be updated in cataloging f 

procedures CT.MEY.04 and CT.MEY.05. If an IPF record does not | 

exist, then the entire bibliographic record must be keyed into j 

the IPF in cataloging procedure CT.MEY.12. j 

As the result of an update or input and a copy command, the f 

INV will be updated and spine labels, book cards, and Meyer j 

short cards will be generated. The spine labels and book card 
will be sent to End Processing for matching with the material. | 

The short card will be sent directly to the Meyer Library. j 

i 

? 

As the final action with the material In all of the j 

cataloging procedures, the call number will be written in the j 

book. Then, depending on whether or not a binding decision is |! 

needed, the material is sent either to the Meyer Library or to 
Binding and Finishing. Neither book cards nor spine labels will be 
generated for items sent tothe Meyer Library; instead, the I PF wi 1 1 
be updated to show that the item has been sent for a binding 
decision. If the material is returned to the Meyer Library for binding j 
in End Processing, then spine labels and book cards will be generated. 

Audio material will be transferred fromthe Audio Library to CT.MEY j 
without previously created IPF records. This I MV will be searched first j 
to see if there are any added copies. If so, they will be returned to tb| 
Audio Library. During the Audio Cataloging procedure (CT.MEY .14), any j 
of the system files can be queried. (Until MARC expands to | 

Include phonodiscs and tapes, this search capability will be 'I 
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limited mainly to checking the I NV as an authority for audio 
cataloging.) The bibliographic data then will be keyed Into the 
IPF/ resulting In an updated I NV and an Audio Short Card that is 
sent directly to the Audio Library. 

Any maintenance of an existing I NV record will be 
accomplished by copying the record into the IPF, keying the 
update/ and moving the updated record back to. the I MV. 

Replacement spine labels/ book cards/ or short cards can be 
generated as needed. Records can also be deleted 
from the I NV in the maintenance function (CT.MEY.19). 

Material that Meyer Library has sent for commercial binding 
will be returned to CT.MEY. For a monograph/ spine labels and a 
book card will be generated as needed/ and the I PF record will be 
updated to show that the item has gone to Binding and Finishing, 
bound serial volume/ the I MV record will be transferred tothe 
IPF so that the holdings can be updated. Any necessary spine 
labels or book card can also be generated. * 
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RULE NO. 

****GM . SYS . POOl 



RULE TEXT 



107.00 35000 

Sort by value of VI or VN/ whichever Is present. 



107.01 24000.39 . ... 

All lines will be terminated at nearest whole word or at the 
hyphen of a hyphenated word. Never break before a hyphen. 
Never break between two hyphens. 



107.02 24000.58 

Count the number of records entering the program . 
Count the number of purchase orders printed. 

Count the number of records not processed. 

Count the number of Abel forms printed. 



107.03 24000.01 

For Formatting of CM. SYS. POOl use form SUL200, lines 1-18, column- 



2 






107.04 24000.04 

Cover sheet , , , . . 

At the beginning of each vendor change, a blank form will be used 

as an address sheet. 

If VI is present in the record, get the vendor name and 
address from the vendor address table. 

If VI is not present, obtain the vendor name and address 
from the data elements VN and-VSD and VCS in the record. 

If Vendor Name is obtained from table, print the name and 
address as stored starting in line 11, column 7. 

The Vendor Name is allowed 31 spaces on each of two lines. 

If. Vendor Name and Address is obtained from record and VN 
has more than 31 characters, start in line 11, column 7. 

Continue printing VN on line 12 column 7. Break the two 
lines at a space or hyphen. 

If VN has less than 31 characters, start in line 12, column 
Print VSD in line 13, column 7. 

Print VCS in line 14, column 7. 

Print a new cover sheet after every. 32 forms for a 

single vendor. If V I =AREL print a new cover sheet after every 

15 purchase orders and 16 Abel original Invoices (32 forms). 
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Title of form: Area #1 

On line 1, column 21 print 

'PURCHASE ORDER' 

On line 3, column 17 print 

'RETURN WITH MATHl I A IL- ■ OR USE AS REPORT 1 
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AUTHOR: 
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RULE TEXT 
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the SUL-200. For these copies 



107.06 24000.03 
If V I =ABE L, print a second copy of 

On line 1, column 24 print 
'ABEL ORIGINAL INVOICE' 

On line 3, column 20 print 

'ABEL ACCOUNTS RECEIVABLE COPY' 

107.07 24000.05 

Date of order: Area #2 

' 3/ 55 ' : : =<0RD> 

107.08 24000.06 

Order number: Area #3 

'3,65' : : =<CRD> 

107.09 24000.07 

If ADD=01 / 02 / 05,06 / 07; or 15 

' 12, 44 ' : : **SH I P<SP( 1)>AMD<SP( 1)>B I LL<SP( 1 )> I N 
, <SP(l)>DUPLICATE<SP(l)>TO: 

13,44 : : =<address from Ship to Address table 
pointed to by value of ADD> 

'14,44' 

' 15,44 1 

'16,44' 

' 18,44' : s=X(30) 

If ADD=03, 04, 08, 09, 10, 11, 12, 13, or 14 

13, 44 * : : =<address from Ship to Address table 
pointed to by value of ADD> 

14,44 ' 

'15,44' 

'16,44' 



ADD are codes which direct 
Address table. The table 
to addresses for all ship to 



Note: The values of data element 

the program to the Ship to 
contains preformatted ship 
add resses . 

107.10 24000.08 

Total estimated price: Area #6 

' 18, 10' : :«(<PR>) 

107.11 24000.09 

Vendor number: Area #7 

'18,36': : = ( <V I > ) 

|<lst 7 non-blank, non-special characters of VN 
with blanks and special characters compressed out.> 



* 186 -v; 

182 » ■ 
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